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

  1. Disallow NAMEDTUPLESTORE RTEs in stored views, rules, etc.

  2. When creating materialized views, use REFRESH to load data.