Re: "SELECT ... FROM DUAL" is not quite as silly as it appears - Mailing list pgsql-hackers

Dear all,

I'm following this list since years - especially PostGIS related - and
you and PG are just awesome!
Pls. let me chime in as a university teacher, therefore used to
explain every year the same things :-).
My 2 cents here are:

Pls. try to give DUAL a better name, since it's IMHO neither
self-explaining nor correct.
Taken from [1], citing the originator:
<<
    The name, DUAL, seemed apt for the process of creating a pair of
rows from just one.[1]
The original DUAL table had two rows in it (hence its name), but
subsequently it only had one row.
<<

My first guess is to name the dummy table with with no columns and one
row "DUMMY" - but I actually want to leave the fun to you to name it.

:Stefan

[1] https://en.wikipedia.org/wiki/DUAL_table

Am So., 27. Jan. 2019 um 21:53 Uhr schrieb Mark Dilger
<hornschnorter@gmail.com>:
>
>
>
> > On Jan 27, 2019, at 12:04 PM, Mark Dilger <hornschnorter@gmail.com> wrote:
> >
> >
> >
> >> On Jan 25, 2019, at 5:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >>
> >> David Rowley <david.rowley@2ndquadrant.com> writes:
> >>> As far as I can see the patch is ready to go, but I'll defer to Mark,
> >>> who's also listed on the reviewer list for this patch.
> >>
> >> Mark, are you planning to do further review on this patch?
> >> I'd like to move it along, since (IMO anyway) we need it in
> >> before progress can be made on
> >> https://commitfest.postgresql.org/21/1664/
> >>
> >>                      regards, tom lane
> >
> >
> > These two observations are not based on any deep understanding of
> > your patch, but just some cursory review:
> >
> > The swtich in src/backend/parser/analyze.c circa line 2819 should
> > probably have an explicit case for RTE_RESULT rather than just a
> > comment and allowing the default to log "unrecognized RTE type",
> > since it's not really unrecognized, just unexpected.  But I'm not
> > too exercised about that, and won't argue if you want to leave it
> > as is.
> >
> > Similarly, in src/backend/commands/explain.c, should there be a
> > case for T_Result in ExplainTargetRel's switch circa line 2974?
> > I'm not sure given your design whether this could ever be relevant,
> > but I noticed that T_Result / RTE_RELATION isn't handled here.
> >
> >
> > Applying your patch and running the regression tests is failing
> > left and right, so I'm working to pull a fresh copy from git and
> > build again -- probably just something wrong in my working directory.
>
> Ok, version 6 of the patch applies cleanly, compiles, and passes
> all tests for me on my platform (mac os x).  You can address the two
> minor observations above, or not, at your option.
>
> mark
>
>