From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | n(dot)lutic(at)loxodata(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17486: [pg_restore] Restoring a view fails if this view contains an attribute without alias name. |
Date: | 2022-05-20 17:05:58 |
Message-ID: | 428377.1653066358@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
I wrote:
> Hmm ... it's a very easy code change, but it results in a lot of
> changes in the regression tests (and I've only tried the core tests
> so far). Given the lack of prior complaints, I wonder if it's going
> to be worth this much behavioral churn.
> It'd be better if we could do this only when the name is actually
> referenced somewhere, but I don't think that's an easy thing to
> determine.
I thought of a compromise position that's not hard to implement:
change the behavior only if the SELECT output column name is *possibly*
visible elsewhere, which it is not in (for example) an EXISTS subquery.
This is easy to keep track of while descending the parse tree.
The attached quick-hack draft results in only one place changing in
the regression tests, and that's a place where a view's visible
column name is already "?column?", so whoever wrote that test case
didn't give a fig for prettiness anyway. This seems like it might be
an acceptable amount of behavioral churn.
Thoughts?
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
display-column-name-when-needed-wip.patch | text/x-diff | 11.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Borodin | 2022-05-20 18:44:21 | Re: BUG #17478: Missing documents in the index after CREATE INDEX CONCURRENTLY (but existing in the table) |
Previous Message | Alvaro Herrera | 2022-05-20 15:23:19 | Re: Implicitly created operator family not listed by pg_event_trigger_ddl_commands |