Re: EphemeralNamedRelation and materialized view
Yugo Nagata <nagata@sraoss.co.jp>
From: Yugo NAGATA <nagata@sraoss.co.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Date: 2024-12-05T14:16:01Z
Lists: pgsql-hackers
Attachments
On Wed, 20 Nov 2024 12:43:16 -0500 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Yugo NAGATA <nagata@sraoss.co.jp> writes: > >> You could even argue that case 2 isn't good enough either, > >> and we should be delivering a specific error message saying > >> that an ENR can't be used in a view/matview. To do that, > >> we'd likely need to pass down the QueryEnvironment in more > >> places not fewer. > > > We can raise a similar error for (not materialized) views by passing > > QueryEnv to DefineView() (or in ealier stage) , but there are other > > objects that can contain ENR in their definition, for examle, functions, > > cursor, or RLS policies. Is it worth introducing this version of error > > message for all these objects? > > If it's worth checking for here, why not in other cases? > > I'm not sure I like using isQueryUsingTempRelation as a model, > because its existing use in transformCreateTableAsStmt seems > like mostly a hack. (And I definitely don't love introducing > yet another scan of the query.) It seems to me that we should > think about this, for MVs as well as those other object types, > as fundamentally a dependency problem. That is, the reason > we can't allow a reference to an ENR in a long-lived object > is that we have no catalog representation for the reference. > So that leads to thinking that the issue ought to be handled > in recordDependencyOnExpr and friends. If we see an ENR while > scanning a rangetable to extract dependencies, then complain. > This might be a bit messy to produce good error messages for, > though. > > Speaking of error messages, I'm not sure that it's okay to > use the phrase "ephemeral named relation" in a user-facing > error message. We don't use that term in our documentation > AFAICS, except in some SPI documentation that most users > will never have read. In the context of triggers, "transition > relation" seems to be what the docs use. Thank you for your suggestion. I've attached a updated patch. Use of ENRs are now checked in find_expr_references_walker() called from recordDependencyOnExpr(). The message is changed to "transition tables cannot be used rule" because the view definition is stored in the pg_rewrite catalog as a rule. Regards, Yugo Nagata -- Yugo NAGATA <nagata@sraoss.co.jp>
Commits
-
Disallow NAMEDTUPLESTORE RTEs in stored views, rules, etc.
- 3c49d462dbcf 18.0 landed
-
When creating materialized views, use REFRESH to load data.
- b4da732fd64e 17.0 cited