Making the subquery alias optional in the FROM clause - Mailing list pgsql-hackers

From Dean Rasheed
Subject Making the subquery alias optional in the FROM clause
Date
Msg-id CAEZATCUCGCf82=hxd9N5n6xGHPyYpQnxW8HneeH+uP7yNALkWA@mail.gmail.com
Whole thread Raw
Responses Re: Making the subquery alias optional in the FROM clause  (Julien Rouhaud <rjuju123@gmail.com>)
Re: Making the subquery alias optional in the FROM clause  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Making the subquery alias optional in the FROM clause  (Erwin Brandstetter <brsaweda@gmail.com>)
List pgsql-hackers
This was discussed previously in [1], and there seemed to be general
consensus in favour of it, but no new patch emerged.

Attached is a patch that takes the approach of not generating an alias
at all, which seems to be neater and simpler, and less code than
trying to generate a unique alias.

It still generates an eref for the subquery RTE, which has a made-up
relation name, but that is marked as not visible on the
ParseNamespaceItem, so it doesn't conflict with anything else, need
not be unique, and cannot be used for qualified references to the
subquery's columns.

The only place that exposes the eref's made-up relation name is the
existing query deparsing code in ruleutils.c, which uniquifies it and
generates SQL spec-compliant output. For example:

CREATE OR REPLACE VIEW test_view AS
  SELECT *
    FROM (SELECT a, b FROM foo),
         (SELECT c, d FROM bar)
   WHERE a = c;

\sv test_view

CREATE OR REPLACE VIEW public.test_view AS
 SELECT subquery.a,
    subquery.b,
    subquery_1.c,
    subquery_1.d
   FROM ( SELECT foo.a,
            foo.b
           FROM foo) subquery,
    ( SELECT bar.c,
            bar.d
           FROM bar) subquery_1
  WHERE subquery.a = subquery_1.c

Regards,
Dean

[1] https://www.postgresql.org/message-id/flat/1487773980.3143.15.camel%40oopsware.de

Attachment

pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Handle infinite recursion in logical replication setup
Next
From: David Geier
Date:
Subject: Re: Lazy JIT IR code generation to increase JIT speed with partitions