From: Tom Lane <tgl@sss.pgh.pa.us>
To: asier.lostale@openbravo.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18038: Aliases removed from view definitions
In-reply-to: <18038-c1613c6a9be9995d@postgresql.org>
References: <18038-c1613c6a9be9995d@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Thu, 27 Jul 2023 06:29:32 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2057265.1690466429.1@sss.pgh.pa.us>
Date: Thu, 27 Jul 2023 10:00:29 -0400
Message-ID: <2057266.1690466429@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2057266.1690466429%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> When defining a view in 16beta2, the sql representing that view removes
> aliases. In previous versions those aliases where kept; furthermore, aliases
> were added even if not defined.

This is not a bug: there is nothing incorrect about either display
of the view.

I believe the proximate cause of the change is that there's a
heuristic in the parsetree decompiler to not attach a table alias to
a Var's name when there is only one relation in the range table (and
thus, no possible ambiguity).  That heuristic has been there for
decades, but it didn't fire in these specific cases because CREATE
VIEW attached some extra hidden range table entries to perform
permissions checking on the view itself.  That doesn't happen anymore
(the permissions checking is handled in another way now), so presto
no redundant alias.

We could alter or remove that heuristic, but not without changing
the behavior in yet other cases, so I doubt that twiddling it
would fix your problem in general.

> In our case this is problematic as in our application we export view
> definitions to text files to later import them, we support different
> PostgreSQL versions and we would need to keep stable SQL among different
> version (export <-> import).

I'm afraid your application has been built on sand.  We change
insignificant details of view/rule decompiling all the time,
and are not likely to stop.  I might have more sympathy for
your request if it didn't imply putting ruleutils.c into an
impossible straitjacket for all time to come.

			regards, tom lane