Re: psql metaqueries with \gexec - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: psql metaqueries with \gexec
Date
Msg-id CADkLM=fQ=GWzAwEUz0+y7CLpG20Ah7bNFbAQn6YXL8YtgXHkRw@mail.gmail.com
Whole thread Raw
In response to Re: psql metaqueries with \gexec  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: psql metaqueries with \gexec  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, Apr 3, 2016 at 4:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
> Jim, can you re-review this?

I'm not Jim, but I have a question: what's the motivation for the
Fortran-order traversal of the result (down rows before across columns)?
It seems less than intuitive to do it that way.  Perhaps there's a good
reason, but I do not see any defense of this choice in the thread.

If I am understanding you correctly, it does work the way you find intuitive: all results from the first row are executed before any in the second row, so

SELECT a, b UNION ALL SELECT c, d

will execute the queries in order: a, b, c, d as is shown in the changes to the sgml and the test cases.

Did you get the impression of Fortran-ordering from the phrase "top-to-bottom, left-to-right order" in the sgml patch? If so, would calling it "rows first" or something else be more clear?

Or am I misunderstanding you and you find the order a, c, b, d more intuitive?

I also note that the patch seems to be missing resetting gexec_flag
in some error exit paths, possibly allowing the \gexec to be applied
to the next query unexpectedly.  It should clear that in all the same
places where gfname or gset_prefix get cleared.

Will do!

I'm only seeing one place where those two vars are deallocated and nulled, and that's at the tail end of SendQuery. Were you expecting more than just that?

pgsql-hackers by date:

Previous
From: Alex Shulgin
Date:
Subject: Re: More stable query plans via more predictable column statistics
Next
From: Tom Lane
Date:
Subject: Re: More stable query plans via more predictable column statistics