Re: [HACKERS] psql metaqueries with \gexec

2016-04-04 Thread Corey Huinker
On Mon, Apr 4, 2016 at 3:31 PM, Tom Lane wrote: > Corey Huinker writes: > > Patch attached. Changes are thus: > > - rebased > > - pset.gexec_flag unconditionally set to false at end of SendQuery > > - wording of documentation describing execution

Re: [HACKERS] psql metaqueries with \gexec

2016-04-04 Thread Tom Lane
Corey Huinker writes: > Patch attached. Changes are thus: > - rebased > - pset.gexec_flag unconditionally set to false at end of SendQuery > - wording of documentation describing execution order of results > - rebasing allowed for undoing the re-wrap of enumerated slash

Re: [HACKERS] psql metaqueries with \gexec

2016-04-03 Thread Corey Huinker
On Sun, Apr 3, 2016 at 8:42 PM, Corey Huinker wrote: > On Sun, Apr 3, 2016 at 7:43 PM, Tom Lane wrote: > >> Corey Huinker writes: >> >>> + The secondary queries are executed in top-to-bottom, >> >>> left-to-right

Re: [HACKERS] psql metaqueries with \gexec

2016-04-03 Thread Corey Huinker
On Sun, Apr 3, 2016 at 7:43 PM, Tom Lane wrote: > Corey Huinker writes: > >>> + The secondary queries are executed in top-to-bottom, > >>> left-to-right order, so the command > > >> I took that as meaning what I said above. > > > Would using

Re: [HACKERS] psql metaqueries with \gexec

2016-04-03 Thread Tom Lane
Corey Huinker writes: >>> + The secondary queries are executed in top-to-bottom, >>> left-to-right order, so the command >> I took that as meaning what I said above. > Would using the term https://en.wikipedia.org/wiki/Row-major_order be more > clear? Meh, I

Re: [HACKERS] psql metaqueries with \gexec

2016-04-03 Thread Corey Huinker
> > + The secondary queries are executed in top-to-bottom, > left-to-right order, so the command > > I took that as meaning what I said above. > > Would using the term https://en.wikipedia.org/wiki/Row-major_order be more clear? The secondary queries are executed in row-major order,

Re: [HACKERS] psql metaqueries with \gexec

2016-04-03 Thread Tom Lane
Corey Huinker writes: > On Sun, Apr 3, 2016 at 4:26 PM, Tom Lane wrote: >> 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)? > If I am understanding you

Re: [HACKERS] psql metaqueries with \gexec

2016-04-03 Thread Corey Huinker
On Sun, Apr 3, 2016 at 4:26 PM, Tom Lane wrote: > Robert Haas 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

Re: [HACKERS] psql metaqueries with \gexec

2016-04-03 Thread Tom Lane
Robert Haas 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

Re: [HACKERS] psql metaqueries with \gexec

2016-03-19 Thread Robert Haas
On Mon, Mar 14, 2016 at 7:54 AM, Corey Huinker wrote: > Patch attached. Changes are thus: > - proper assignment of success var > - added documentation to psql manpage/html with examples pulled from > regression tests. > > Not changed are: > - exuberant braces, can remove

Re: [HACKERS] psql metaqueries with \gexec

2016-03-14 Thread Corey Huinker
> > > I'm getting a warning from this patch: > > 1 warning generated. > Fixed that one. (note that I'm using CC='ccache clang -Qunused-arguments > -fcolor-diagnostics') > > for (r = 0; r < nrows; r++) >> { >> for (c = 0; c < ncolumns; c++) >> { >>

Re: [HACKERS] psql metaqueries with \gexec

2016-03-13 Thread Jim Nasby
The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:not tested Still needs documentation. The new status of this patch is: Waiting

Re: [HACKERS] psql metaqueries with \gexec

2016-03-13 Thread Jim Nasby
On 2/22/16 1:01 PM, Corey Huinker wrote: In the mean time, update patch attached. Really attached this time. I'm getting a warning from this patch: common.c:947:8: warning: variable 'success' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]

Re: format() changes discussion (was: Re: [HACKERS] psql metaqueries with \gexec)

2016-02-22 Thread Jim Nasby
On 2/22/16 5:16 PM, Corey Huinker wrote: (One thing I had to come up with was processing of arrays, which you also see in that example JSON -- it's the specifiers that have a colon inside the {}. The part after the colon is used as separator between the array elements, and each

Re: [HACKERS] psql metaqueries with \gexec

2016-02-22 Thread Jim Nasby
On 2/22/16 5:13 PM, Alvaro Herrera wrote: Jim Nasby wrote: On 2/22/16 11:47 AM, Alvaro Herrera wrote: Pavel Stehule wrote: The design of the "format" function is not closed. Try to send prototype and patch. The possibility to do PostgreSQL customization was strong reason why we didn't

format() changes discussion (was: Re: [HACKERS] psql metaqueries with \gexec)

2016-02-22 Thread Corey Huinker
> > (One thing I had to come up with was processing of arrays, which you > also see in that example JSON -- it's the specifiers that have a colon > inside the {}. The part after the colon is used as separator between > the array elements, and each element is expanded separately.) > > I'm

Re: [HACKERS] psql metaqueries with \gexec

2016-02-22 Thread Alvaro Herrera
Jim Nasby wrote: > On 2/22/16 11:47 AM, Alvaro Herrera wrote: > >Pavel Stehule wrote: > > > >>The design of the "format" function is not closed. Try to send prototype > >>and patch. The possibility to do PostgreSQL customization was strong reason > >>why we didn't implemented "sprintf" and we

Re: [HACKERS] psql metaqueries with \gexec

2016-02-22 Thread Jim Nasby
On 2/22/16 11:47 AM, Alvaro Herrera wrote: Pavel Stehule wrote: The design of the "format" function is not closed. Try to send prototype and patch. The possibility to do PostgreSQL customization was strong reason why we didn't implemented "sprintf" and we implemented "format". Probably not

Re: [HACKERS] psql metaqueries with \gexec

2016-02-22 Thread Corey Huinker
> > In the mean time, update patch attached. > > Really attached this time. diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c index 9750a5b..5ca769f 100644 --- a/src/bin/psql/command.c +++ b/src/bin/psql/command.c @@ -849,6 +849,13 @@ exec_command(const char *cmd, status

Re: [HACKERS] psql metaqueries with \gexec

2016-02-22 Thread Corey Huinker
On Mon, Feb 22, 2016 at 11:30 AM, Corey Huinker wrote: > On Mon, Feb 22, 2016 at 10:08 AM, Daniel Verite > wrote: > >> Corey Huinker wrote: >> >> > ...and query text visibility, and result visibility, and error handling, >> > etc. In

Re: [HACKERS] psql metaqueries with \gexec

2016-02-22 Thread Alvaro Herrera
Pavel Stehule wrote: > The design of the "format" function is not closed. Try to send prototype > and patch. The possibility to do PostgreSQL customization was strong reason > why we didn't implemented "sprintf" and we implemented "format". Probably not terribly useful here, but for the

Re: [HACKERS] psql metaqueries with \gexec

2016-02-22 Thread Corey Huinker
On Mon, Feb 22, 2016 at 10:08 AM, Daniel Verite wrote: > Corey Huinker wrote: > > > ...and query text visibility, and result visibility, and error handling, > > etc. In this case, we're leveraging the psql environment we'd already set > > up, and if there's an

Re: [HACKERS] psql metaqueries with \gexec

2016-02-22 Thread Daniel Verite
Corey Huinker wrote: > ...and query text visibility, and result visibility, and error handling, > etc. In this case, we're leveraging the psql environment we'd already set > up, and if there's an error, \set ECHO queries shows us the errant SQL as > if we typed it ourselves.. BTW, about

Re: [HACKERS] psql metaqueries with \gexec

2016-02-22 Thread Pavel Stehule
> > FWIW, I also wish we had something better than format() for this stuff. I > did create [1] towards that end, but it currently depends on some C code, > which is cumbersome. For the most party, I'm pretty thrilled with format(), though: - I'll admit to being grumpy about the %1$s notation,

Re: [HACKERS] psql metaqueries with \gexec

2016-02-22 Thread Corey Huinker
> > I like what you've proposed, though I am wondering if you considered doing > something server-side instead? It seems a shame to do all this work and > exclude all other tools. > I have, but my solutions closely mirror the one you mention in the next paragraph. > I frequently find myself

Re: [HACKERS] psql metaqueries with \gexec

2016-02-21 Thread Jim Nasby
On 2/19/16 7:32 PM, Corey Huinker wrote: Wow, and I thought *I* liked metaprogramming! :) I like what you've proposed, though I am wondering if you considered doing something server-side instead? It seems a shame to do all this work and exclude all other tools. I frequently find myself

[HACKERS] psql metaqueries with \gexec

2016-02-19 Thread Corey Huinker
Often, I'm faced with a long .sql script that builds some objects, then builds things on top of them. This means that some of the queries I wish to run are dependent on the state of things that are unknown at the time of writing the script. I could give up, and make a python script that mostly