Is it possible to get the name of a table at runtime?

[ThomasVille]

Backend

SQLite

Diesel version

2.2.12

Diesel Features

sqlite, uuid, returning_clauses_for_sqlite_3_35, chrono

Operating System Version

Ubuntu 25.04 x86_64 GNU/Linux 6.14.0-32-generic

Third party libraries

No response

What do you want to do?

I'm trying to get the name of a table declared using the DSL like in the getting_started_step_1 example statically at runtime.

I didn't find anything in the self::schema::posts module so I looked at the expanded code of the example with cargo expand --lib and the only string for "posts" I found is an internal one that I'm likely not supposed to be able to access:

impl diesel::internal::table_macro::StaticQueryFragment for table {
    type Component = diesel::internal::table_macro::Identifier<'static>;
    const STATIC_COMPONENT: &'static Self::Component = &diesel::internal::table_macro::Identifier(
        "posts",
    );
}

I already looked at the documentation, the feature flags, the code of diesel and didn't find any solution.

Ideally I'd like to do something like:

println!("Table name: {}", self::schema::posts::table_name);

And it would print:

Table name: posts

Compile time error

No response

What code do you already have?

Right now, the only solution I see is to write a macro that allows me to write:

#[derive(Queryable, Selectable)]
#[diesel(table_name = crate::schema::posts)]
#[diesel(check_for_backend(diesel::sqlite::Sqlite))]
// Add a macro here that will extract the name of the module and inject the string in a static const.
#[table_name(crate::schema::posts)]
pub struct Post {
    pub id: i32,
    pub title: String,
    pub body: String,
    pub published: bool,
}


The macro would then generate something like:
```rust
trait HasTableName {
    const TABLE_NAME: &'static str;
}

impl HasTableName for Posts {
    const TABLE_NAME: &'static str = "posts";
}

So that I could get the name of the table with:

Posts::TABLE_NAME

Thanks to everyone reading my post.

### Additional details

_No response_

### Checklist

- [X] I have already looked over the [issue tracker](https://github.com/diesel-rs/diesel/issues) and the [discussion forum](https://github.com/diesel-rs/diesel/discussions) for similar possible closed issues.

[weiznich]

This information is currently not exposed in such a way.

It would be interesting to learn more about your use-case to understand if we should expose this information or if this is already covered by another API.

[mathewmeconry]

I currently run into a similar issue. I have a materialized view in my PostgreSQL database that I want to update in specific cases during the application lifecycle.
For now, I hardcoded the view name into the query REFRESH query, but it is not a good practice from my point of view.

[weiznich]

For this particular case you don't need to have access to the name as string as you can simply write your own custom query DSL extension for REFRESH.

Something like this should work:

#[derive(QueryId)]
struct Refresh<T>(T);

impl<T> QueryFragment<Pg> for Refresh<T> where T: Table {
     fn walk_ast<'b>(&'b self, mut pass: AstPass<'_, 'b, Pg>) -> QueryResult<()> {
          pass.push_sql("REFRESH ");
          self.0.walk_ast(pass)?;
          Ok(())
     }
}

impl<T> RunQueryDsl<PgConnection> for Refresh<T> {}

// use it like that:
Refresh(your::table).execute(conn)?;

[LucaCappelletti94]

Hi - I am facing the same problem, in my use case it is currently primarily for better error reporting. I have some structs associated to the table, and I would like to be able to format an error like format!("Something something is wrong for struct associated to table {}"). It is currently possible to do the same for columns, since there exists Column::NAME. Something analogous for table would be nice, maybe a new NamedTable trait to avoid breaking the API of the Table trait itself.

[weiznich]

You likely can use QueryFragment::to_sql for this. It might not be as accessible as a plain to_string or whatever method, but it should give you the correct identifier.

[LucaCappelletti94]

The issue with this solution is that to_sql requires to provide the out: &mut DB::QueryBuilder, backend: &DB, which are not available in the context of the error.

[weiznich]

It's hard to answer that without knowing more context. Strictly speaking nothing is stopping you from exposing these information to your error context. Also they are required to get the actual SQL and not just an approximation as that is depended exactly on the query builder and the backend. Different implementations just will lead to different results there, even for table names.

[LucaCappelletti94]

Basically, I am currently working on a dynamic dispatching that looks like the following, where I use TABLE_NAME to filter a map. At this time, I have created a TableExtension trait with an associated const type TABLE_NAME, but if there was an alternative way to retrieve the table name without re-defining the const I would prefer it.

pub fn dispatch<T: TableExtension>(
        mut self,
        map: impl FnMut(TableBuilder<T>, &mut C) -> Result<(), E>,
    ) -> Result<Self, E> {
          for child in self.children() {
               if child.table_name() == T::TABLE_NAME {
                      map(T::builder(child), self.collection)?;
               }
          }
          Ok(self)
    }

Could you clarify what you meant by Different implementations just will lead to different results there, even for table names.? Do different backends have different outputs for the table name?

[weiznich]

Could you clarify what you meant by Different implementations just will lead to different results there, even for table names.? Do different backends have different outputs for the table name?

The query builder also handles quoting the table and escaping dangerous parts of the identifier. That's backend depended as different backends use different quotation styles (' vs ")

Basically, I am currently working on a dynamic dispatching that looks like the following, where I use TABLE_NAME to filter a map. At this time, I have created a TableExtension trait with an associated const type TABLE_NAME, but if there was an alternative way to retrieve the table name without re-defining the const I would prefer it.

I think you should be able to use table.type_id() and std::any::type_name::<table>() for that