Re: BUG #17486: [pg_restore] Restoring a view fails if this view contains an attribute without alias name.

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 19:06:53
Message-ID: EC735F33-1AA3-4FA9-8054-0C949B70AB15@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> On 20 May 2022, at 19:05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> 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.

Nice one! I think that's even better than the previous version actually.
Skimming the patch it seems like a reasonable approach.

--
Daniel Gustafsson https://vmware.com/

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2022-05-21 03:14:39 Re: Implicitly created operator family not listed by pg_event_trigger_ddl_commands
Previous 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)