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 order of results
> > - rebasing allowed for undoi
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 commands.
I whacked this a
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 order, so the command
>>
>> >> I took that as meaning what I said above.
>
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 the term https://en.wikipedia.org/wiki/Row-maj
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 suspect a lot of people don'
>
> + 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, s
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 correctly, it does work the way you find
> intuitiv
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 seems less than intuitive to do it that way
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 I do not see any defens
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 if someone wants me to
>
>
>
> 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++)
>> {
>>
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
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]
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 e
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 impleme
>
> (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 splitting
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 imple
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 te
>
> 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
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 this case, we're leveraging the psql environment we'd
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 DDL-depar
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 error, \set ECHO queries sho
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 e
>
> 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, but
>
> 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 crea
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 creat
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 ju
27 matches
Mail list logo
