From: | Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: EphemeralNamedRelation and materialized view |
Date: | 2024-12-05 14:16:01 |
Message-ID: | 20241205231601.73aa0ed696570e2a7b12c454@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 20 Nov 2024 12:43:16 -0500
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Yugo NAGATA <nagata(at)sraoss(dot)co(dot)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(at)sraoss(dot)co(dot)jp>
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Prohibit-materialized-views-to-use-ephemeral-name.patch | text/x-diff | 4.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2024-12-05 14:43:08 | Re: attndims, typndims still not enforced, but make the value within a sane threshold |
Previous Message | Bertrand Drouvot | 2024-12-05 14:13:58 | Re: shared-memory based stats collector - v70 |