| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Daniel Verite <daniel(at)manitou-mail(dot)org>, PostgreSQL <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: psql metaqueries with \gexec |
| Date: | 2016-04-03 20:26:14 |
| Message-ID: | 7569.1459715174@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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.
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2016-04-03 20:32:28 | Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby |
| Previous Message | Alex Shulgin | 2016-04-03 20:14:38 | Re: More stable query plans via more predictable column statistics |