On 9/25/17 13:53, Fabien COELHO wrote:
> \d+ does not show more.
>
> Maybe Type, Min, Max, Inc & Cycles are enough for \d?
That seems kind of arbitrary. Start and Cache are just as relevant.
> The next/future or last/previous value is not shown. If one could be
> available it would be nice to
Hello,
This should be fixed for PG10, so if you have any feedback on the
design, please let me know soon.
Works for me on head against a 9.6 server, which is good.
My 0.02 €:
\d+ does not show more.
Maybe Type, Min, Max, Inc & Cycles are enough for \d?
The next/future or last/previous val
In PostgreSQL 10, the sequence metadata moved from the sequence
"relation" to a system catalog. The psql \d sequence command was not
updated for that. (It just did SELECT * FROM seq and there were no
tests, so this was missed.) Attached is a patch that fixes that up,
taking the opportunity to de
Correct Fabien. I have already removed myself as a reviewer. Thanks.
As you wish!
Thanks for the feedback, which I understood as "works for me".
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/
Correct Fabien. I have already removed myself as a reviewer. Thanks.
-
robins | mobile
On 20 Sep. 2017 5:13 pm, "Fabien COELHO" wrote:
>
> Hello Robins,
>
> I was able to test the functionality (which seemed to work fine) and fed in
>> my comment to assist anyone else reviewing this patch (and
Hello Robins,
I was able to test the functionality (which seemed to work fine) and fed in
my comment to assist anyone else reviewing this patch (and intentionally
let it's state as 'Needs Review').
While trying to provide my feedback, on hindsight I should have been more
detailed about what I
I was able to test the functionality (which seemed to work fine) and fed in my
comment to assist anyone else reviewing this patch (and intentionally let it's
state as 'Needs Review').
While trying to provide my feedback, on hindsight I should have been more
detailed about what I didn't test. Be
Hi Fabien,
I was able to test the functionality (which seemed to work fine) and fed in
my comment to assist anyone else reviewing this patch (and intentionally
let it's state as 'Needs Review').
While trying to provide my feedback, on hindsight I should have been more
detailed about what I didn't
Hello Robins,
Thanks for the review.
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, failed
Where ?
Spec compliant: not tested
Documentation:tested, failed
Where ? I just
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, failed
Spec compliant: not tested
Documentation:tested, failed
The patch applies cleanly and compiles + installs fine (although am u
2017-09-18 11:44 GMT+02:00 Alvaro Herrera :
> Pavel Stehule wrote:
>
> > I am looking on man pagers - and there are very well readable
> >
> > The rules are simply - when some variables are short - less than 6 chars,
> > then it description and label are on same line. Between items are empty
> > l
Pavel Stehule wrote:
> I am looking on man pagers - and there are very well readable
>
> The rules are simply - when some variables are short - less than 6 chars,
> then it description and label are on same line. Between items are empty
> line
I was having a similar idea. I'm not sure how many
2017-09-14 16:35 GMT+02:00 Pavel Stehule :
>
>
> 2017-09-14 15:17 GMT+02:00 Alvaro Herrera :
>
>> Tom Lane wrote:
>> > "David G. Johnston" writes:
>> > >If I was going to try and read it like a book I'd want the extra
>> > > white-space to make doing so easier (white-space gives the eye a
>> bre
2017-09-14 15:17 GMT+02:00 Alvaro Herrera :
> Tom Lane wrote:
> > "David G. Johnston" writes:
> > >If I was going to try and read it like a book I'd want the extra
> > > white-space to make doing so easier (white-space gives the eye a
> breather
> > > when done with a particular concept) - and t
Tom Lane wrote:
> "David G. Johnston" writes:
> >If I was going to try and read it like a book I'd want the extra
> > white-space to make doing so easier (white-space gives the eye a breather
> > when done with a particular concept) - and the length wouldn't really
> > matter since I'd just make
Hello,
Personnally I'm fine with a pager, so vertical spacing is fine. I just do
not like paging horizontally.
-1 [...]
If I was going to try and read it like a book I'd want the extra
white-space to make doing so easier (white-space gives the eye a breather
when done with a particular co
"David G. Johnston" writes:
>If I was going to try and read it like a book I'd want the extra
> white-space to make doing so easier (white-space gives the eye a breather
> when done with a particular concept) - and the length wouldn't really
> matter since I'd just make a single pass and be done
On Wed, Sep 13, 2017 at 12:46 PM, Fabien COELHO wrote:
>
> Hello Tom,
>
> Probably it needs some rebase after Tom committed result status variables.
>>>
>>
>> As it is a style thing, ISTM that the patch is ready if most people agree
>>> that it is better this way and there is no strong veto again
Hello Tom,
Probably it needs some rebase after Tom committed result status variables.
As it is a style thing, ISTM that the patch is ready if most people agree
that it is better this way and there is no strong veto against.
FWIW, I think it's a bad idea. We already nearly-doubled the vert
Alvaro Herrera writes:
> Why is it that we're not opening the pager automatically when this help
> is invoked via psql --help=variables? "\? variables" already does that.
Hm, given that output from a -c option does get paginated (I just
checked), maybe that should happen.
Most of the time I suppose you'd search (using the pager's search
function) whatever you're looking for, rather than read the whole
page from top to bottom.
Why is it that we're not opening the pager automatically when this help
is invoked via psql --help=variables? "\? variables" already does th
2017-09-13 16:11 GMT+02:00 Tom Lane :
> Fabien COELHO writes:
> >> I'll assign this patch to next commitfest
>
> > Probably it needs some rebase after Tom committed result status
> variables.
>
> > As it is a style thing, ISTM that the patch is ready if most people agree
> > that it is better thi
Fabien COELHO writes:
>> I'll assign this patch to next commitfest
> Probably it needs some rebase after Tom committed result status variables.
> As it is a style thing, ISTM that the patch is ready if most people agree
> that it is better this way and there is no strong veto against.
FWIW, I t
One thing we could think about if this seems too high is to drop
ROW_COUNT. I'm unconvinced that it has a real use-case, and it seems
to be taking more than its share of the work in non-error cases, because
it turns out that PQcmdTuples() is not an amazingly cheap function.
I do think that a
Hello Tom,
I put back SetResultVariables function which is called twice, for SQL
queries and the new descriptions. It worked out of the box with DECLARE
which is just another SQL statement, so maybe I did not understood the
cursor issue you were signaling...
No, I was concerned about ExecQuer
Finally, as vertical scrolling is mandatory, I would be fine with
skipping lines with entries for readability, but it is just a matter of
taste and I expect there should be half a dozen different opinions on
the matter of formatting.
FWIW, +1 to extra lines from me - I find it way more readabl
2017-09-09 1:30 GMT+02:00 Alvaro Herrera :
> Tomas Vondra wrote:
>
> > > Finally, as vertical scrolling is mandatory, I would be fine with
> > > skipping lines with entries for readability, but it is just a matter of
> > > taste and I expect there should be half a dozen different opinions on
> > >
Fabien COELHO writes:
> See v9 attached.
I've pushed this with some editorialization.
> I put back SetResultVariables function which is called twice, for SQL
> queries and the new descriptions. It worked out of the box with DECLARE
> which is just another SQL statement, so maybe I did not unde
Well, if we provided a different SQLSTATE for each qualitatively
different type of libpq error, that might well be useful enough to
justify some risk of application breakage. But replacing a constant
string that we've had for ~15 years with a different constraint string
isn't doing anything abo
Robert Haas writes:
> Well, if we provided a different SQLSTATE for each qualitatively
> different type of libpq error, that might well be useful enough to
> justify some risk of application breakage. But replacing a constant
> string that we've had for ~15 years with a different constraint strin
On Tue, Sep 12, 2017 at 3:12 PM, Tom Lane wrote:
>> I think this is a bad plan. Right now, libpq sets no SQLSTATE for
>> internally generated errors; it is almost certain that there are
>> applications testing for an empty SQLSTATE to notice when they're
>> getting an error from libpq. Enterpris
Robert Haas writes:
> On Tue, Sep 12, 2017 at 1:23 PM, Fabien COELHO wrote:
>> I added two error codes, which is debatable. One is used hardcoded by libpq
>> if no diagnostic is found, and the other by psql if libpq returned something
>> empty, which might happen if psql is linked with an older l
2017-09-12 20:43 GMT+02:00 Robert Haas :
> On Tue, Sep 12, 2017 at 1:23 PM, Fabien COELHO
> wrote:
> > I added two error codes, which is debatable. One is used hardcoded by
> libpq
> > if no diagnostic is found, and the other by psql if libpq returned
> something
> > empty, which might happen if
On Tue, Sep 12, 2017 at 1:23 PM, Fabien COELHO wrote:
> I added two error codes, which is debatable. One is used hardcoded by libpq
> if no diagnostic is found, and the other by psql if libpq returned something
> empty, which might happen if psql is linked with an older libpq, maybe. I do
> not kn
Hello Tom,
Yep, I thought I was optimistic:-) Can I add a special SQLSTATE for that
situation where libpq did not report an error?
Meh. If we're going to do that I think it might be better to hack
libpq itself to do so, ie, force PQresultErrorField(..., PG_DIAG_SQLSTATE)
to always return som
2017-09-11 20:46 GMT+02:00 Fabien COELHO :
>
> I think you're overly optimistic to believe that every failure will
have a SQLSTATE; I don't think that's true for libpq-reported errors,
such as connection loss.
>>>
>> Yep, I thought I was optimistic:-) Can I add a special SQLSTATE fo
I think you're overly optimistic to believe that every failure will
have a SQLSTATE; I don't think that's true for libpq-reported errors,
such as connection loss.
Yep, I thought I was optimistic:-) Can I add a special SQLSTATE for that
situation where libpq did not report an error?
Meh. If
Fabien COELHO writes:
>> I think you're overly optimistic to believe that every failure will
>> have a SQLSTATE; I don't think that's true for libpq-reported errors,
>> such as connection loss.
> Yep, I thought I was optimistic:-) Can I add a special SQLSTATE for that
> situation where libpq did
Hello Tom,
Hm. Looking closer at this, I see that it doesn't work so well after all
to put the variable-setting code in ProcessResult:
that fails to cover the ExecQueryUsingCursor code path.
Ok, I'll investigate this path.
And it also fails to cover DescribeQuery, which arguably should set
Fabien COELHO writes:
> Small v7 update, sorry for the noise.
Hm. Looking closer at this, I see that it doesn't work so well after all
to put the variable-setting code in ProcessResult: that fails to cover the
ExecQueryUsingCursor code path. And it also fails to cover DescribeQuery,
which argua
Tomas Vondra wrote:
> > Finally, as vertical scrolling is mandatory, I would be fine with
> > skipping lines with entries for readability, but it is just a matter of
> > taste and I expect there should be half a dozen different opinions on
> > the matter of formatting.
>
> FWIW, +1 to extra lines
Tomas Vondra wrote:
> That's not what I meant. I've never felt a strong urge to avoid wrapping
> at 80 chars when translating strings - simply translate in the most
> meaningful way, if it gets longer than 80 chars and can't be easily
> shortened, just wrap. If there are 60 or 80 character
On 09/09/2017 01:24 AM, Tom Lane wrote:
> Tomas Vondra writes:
>> The translator has exactly the same context in both cases, and the
>> struggle to wrap it at 80 characters will be pretty much the same too.
>
> Really? With the old way, you had something under 60 characters to
> work in, now it'
Hi
2017-09-09 1:24 GMT+02:00 Tom Lane :
> Tomas Vondra writes:
> > The translator has exactly the same context in both cases, and the
> > struggle to wrap it at 80 characters will be pretty much the same too.
>
> Really? With the old way, you had something under 60 characters to
> work in, now
Tomas Vondra writes:
> The translator has exactly the same context in both cases, and the
> struggle to wrap it at 80 characters will be pretty much the same too.
Really? With the old way, you had something under 60 characters to
work in, now it's nearly 80. I don't buy that that's not a signif
Hi,
On 09/08/2017 07:25 AM, Fabien COELHO wrote:
>
> Hello,
>
>>> PSQL_HISTORY alternative location for the command history file
>>>
>>> I would prefer to revert to that more compact 9.6-formatting.
>>
>> There was a problem with line width .. its hard to respect 80 chars
>
> Yes.
>
>
Hello,
PSQL_HISTORY alternative location for the command history file
I would prefer to revert to that more compact 9.6-formatting.
There was a problem with line width .. its hard to respect 80 chars
Yes.
Scrolling in two dimensions because it does not fit either way is not too
p
2017-09-08 6:36 GMT+02:00 Erik Rijkers :
> On 2017-09-08 06:09, Pavel Stehule wrote:
>
>> Hi
>>
>> Now the output looks like:
>>
>> AUTOCOMMIT
>> if set, successful SQL commands are automatically committed
>> COMP_KEYWORD_CASE
>> determines the case used to complete SQL key words
>>
On 2017-09-08 06:09, Pavel Stehule wrote:
Hi
Now the output looks like:
AUTOCOMMIT
if set, successful SQL commands are automatically committed
COMP_KEYWORD_CASE
determines the case used to complete SQL key words
[lower, upper, preserve-lower, preserve-upper]
DBNAME
the cur
Hi
Now the output looks like:
AUTOCOMMIT
if set, successful SQL commands are automatically committed
COMP_KEYWORD_CASE
determines the case used to complete SQL key words
[lower, upper, preserve-lower, preserve-upper]
DBNAME
the currently connected database name
ECHO
co
Hello Pavel,
I checked performance - the most fast queries are execution of simple
prepared statement
prepare x as select 1;
-- 100 x
execute x;
execute x;
execute x;
execute x;
## patched
[pavel@nemesis postgresql]$ time psql -At -1 postgres -f ~/xxx.sql >
/dev/null
real 0m44,887s
user
Hi
2017-09-06 11:14 GMT+02:00 Fabien COELHO :
>
> Here is a version 6.
>>
>
> Small v7 update, sorry for the noise.
>
> Add testing the initial state of all variables.
>
> Fix typos in a comment in tests.
>
> Fix the documentation wrt the current implementation behavior.
I rechecked last patch
Here is a version 6.
Small v7 update, sorry for the noise.
Add testing the initial state of all variables.
Fix typos in a comment in tests.
Fix the documentation wrt the current implementation behavior.
--
Fabien.diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
Hello Tom,
Here is a version 6.
A few thoughts about this patch:
* I think the ERROR_CODE variable should instead be named SQLSTATE.
That is what the SQL standard calls this string, and it's also what
just about all our documentation calls it; see PG_DIAG_SQLSTATE
in libpq, or the SQLSTATE 'x
* It might be better if SQLSTATE and ERROR_MESSAGE were left
unchanged by a non-error query.
Hmmm. I'm not sure. If so, ERROR_MESSAGE should be LAST_ERROR_MESSAGE
maybe? Then what about LAST_ERROR_SQLSTATE to go with it, and let SQLSTATE
& ERROR_MESSAGE reflect the last command, and ERROR is
Fabien COELHO writes:
>> * It might be better if SQLSTATE and ERROR_MESSAGE were left
>> unchanged by a non-error query.
> Hmmm. I'm not sure. If so, ERROR_MESSAGE should be LAST_ERROR_MESSAGE
> maybe? Then what about LAST_ERROR_SQLSTATE to go with it, and let SQLSTATE
> & ERROR_MESSAGE reflect
Hello Tom,
* I think the ERROR_CODE variable should instead be named SQLSTATE.
That is what the SQL standard calls this string, and it's also what
just about all our documentation calls it; see PG_DIAG_SQLSTATE
in libpq, or the SQLSTATE 'x' construct in pl/pgsql, or the
sqlstate attribute o
A few thoughts about this patch:
* I think the ERROR_CODE variable should instead be named SQLSTATE.
That is what the SQL standard calls this string, and it's also what
just about all our documentation calls it; see PG_DIAG_SQLSTATE
in libpq, or the SQLSTATE 'x' construct in pl/pgsql, or the
s
I don't doubt about a sense of this configuration - but this specific
combination depends on usage - so I don't think so using special option is
good idea.
Although I agree with you that detailed settings are definitely debatable,
I'd say that at least it would be a more reasonable starting p
2017-08-28 11:05 GMT+02:00 Craig Ringer :
> On 28 August 2017 at 16:23, Fabien COELHO wrote:
>
>>
>> This doesn't really address the original issue though, that it's far from
>>> obvious how to easily and correctly script psql.
>>>
>>
>> That is another interesting argument. I understood that the
On 28 August 2017 at 16:23, Fabien COELHO wrote:
>
> This doesn't really address the original issue though, that it's far from
>> obvious how to easily and correctly script psql.
>>
>
> That is another interesting argument. I understood that the issue was
> having to type these options, but now i
This doesn't really address the original issue though, that it's far from
obvious how to easily and correctly script psql.
That is another interesting argument. I understood that the issue was
having to type these options, but now it is also to remember which one are
relevant and wanted, whi
On 28 August 2017 at 15:34, Pavel Stehule wrote:
>
>
> 2017-08-28 9:33 GMT+02:00 Fabien COELHO :
>
>>
>> ISTM that the real pain is the "-v ON_ERRORS_STOP=1" which I occasionally
encountered as well, the other one letter ones are not too bad. Maybe it
would be enough to have a shortcut
2017-08-28 9:33 GMT+02:00 Fabien COELHO :
>
> ISTM that the real pain is the "-v ON_ERRORS_STOP=1" which I occasionally
>>> encountered as well, the other one letter ones are not too bad. Maybe it
>>> would be enough to have a shortcut for this one, say "-B"?
>>>
>>
>> I agree with last sentence.
ISTM that the real pain is the "-v ON_ERRORS_STOP=1" which I occasionally
encountered as well, the other one letter ones are not too bad. Maybe it
would be enough to have a shortcut for this one, say "-B"?
I agree with last sentence. I don't think so -qAtX are expected always, but
"-v ON_ERROR
2017-08-28 8:56 GMT+02:00 Fabien COELHO :
>
> I find myself regurgitating the incantation
>>
>> psql -qAtX -v ON_ERRORS_STOP=1
>>
>> quite a bit. It's not ... super friendly.
>>
>> It strikes me that we could possibly benefit from a 'psql --batch' option.
>>
>> Thoughts?
>>
>
> The link between -q
On 28 August 2017 at 14:56, Fabien COELHO wrote:
>
> I find myself regurgitating the incantation
>>
>> psql -qAtX -v ON_ERRORS_STOP=1
>>
>> quite a bit. It's not ... super friendly.
>>
>> It strikes me that we could possibly benefit from a 'psql --batch' option.
>>
>> Thoughts?
>>
>
> The link be
I find myself regurgitating the incantation
psql -qAtX -v ON_ERRORS_STOP=1
quite a bit. It's not ... super friendly.
It strikes me that we could possibly benefit from a 'psql --batch' option.
Thoughts?
The link between -qAtX and "batch" is not that fully obvious, especially
the unaligned
Hi all
I find myself regurgitating the incantation
psql -qAtX -v ON_ERRORS_STOP=1
quite a bit. It's not ... super friendly.
It strikes me that we could possibly benefit from a 'psql --batch' option.
Thoughts?
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Developm
Here is a version with the :{?varname} syntax.
It looks much better for me.
I'll admit that it looks better to me as well:-)
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hack
On Sat, Aug 26, 2017 at 2:09 PM, Pavel Stehule
wrote:
>
>
> 2017-08-26 19:55 GMT+02:00 Fabien COELHO :
>
>>
>> Any colon prefixed syntax can be made to work because it is enough for
>>> the lexer to detect and handle... so
>>>
>>> :{defined varname}
>>>
>>> may be an option, although I do not li
2017-08-26 19:55 GMT+02:00 Fabien COELHO :
>
> Any colon prefixed syntax can be made to work because it is enough for the
>> lexer to detect and handle... so
>>
>> :{defined varname}
>>
>> may be an option, although I do not like the space much because it adds
>> some fuzzyness in the lexer which
Any colon prefixed syntax can be made to work because it is enough for the
lexer to detect and handle... so
:{defined varname}
may be an option, although I do not like the space much because it adds some
fuzzyness in the lexer which has to process it. It is probably doable,
though. I like
Hello Pavel,
As a follow-up to the \if patch by Corey Huinker, here is a proposal to
allow testing whether a client-side variable exists in psql.
The syntax is as ugly as the current :'var' and :"var" things, but ISTM
that this is the only simple option to have a working SQL-compatible syntax
2017-08-26 8:54 GMT+02:00 Fabien COELHO :
>
> Hello,
>
> As a follow-up to the \if patch by Corey Huinker, here is a proposal to
> allow testing whether a client-side variable exists in psql.
>
> The syntax is as ugly as the current :'var' and :"var" things, but ISTM
> that this is the only simple
Hello,
As a follow-up to the \if patch by Corey Huinker, here is a proposal to
allow testing whether a client-side variable exists in psql.
The syntax is as ugly as the current :'var' and :"var" things, but ISTM
that this is the only simple option to have a working SQL-compatible
syntax wit
2017-06-28 10:04 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> + if (success)
>> + {
>> + char *ntuples = PQcmdTuples(results);
>> + SetVariable(pset.vars, "ROW_COUNT", *ntuples ? ntuples : "0");
>> + SetVariable(pset.vars, "ERROR", "FALSE");
>> + }
>> + else
>> + {
>> + SetVariable(pset.vars,
Hello Pavel,
+ if (success)
+ {
+ char *ntuples = PQcmdTuples(results);
+ SetVariable(pset.vars, "ROW_COUNT", *ntuples ? ntuples : "0");
+ SetVariable(pset.vars, "ERROR", "FALSE");
+ }
+ else
+ {
+ SetVariable(pset.vars, "ROW_COUNT", "0");
+ SetVariable(pset.vars, "ERROR", "TRUE");
+ }
+}
It
2017-06-28 9:25 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> I agree that the existing "SetVariableBool" function is a misnommer, it
>>> should be "SetVariableOn" given what it does, and it is not what we need.
>>>
>>
>> switching default setting from ON to TRUE requires wider discussion -
>>
>
Hello Pavel,
I agree that the existing "SetVariableBool" function is a misnommer, it
should be "SetVariableOn" given what it does, and it is not what we
need.
switching default setting from ON to TRUE requires wider discussion -
Yep.
in this moment I like to have special function "SetVar
2017-06-27 17:30 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> We can introduce macro SetVariableBool(vars, varname, bool) instead
>>>
>>> SetVariable(pset.vars, "ERROR", "FALSE");
>>>
>>
>> I checked source code, and it requires little bit more harder refactoring
>> because now we have SetVaria
Hello Pavel,
We can introduce macro SetVariableBool(vars, varname, bool) instead
SetVariable(pset.vars, "ERROR", "FALSE");
I checked source code, and it requires little bit more harder refactoring
because now we have SetVariableBool - what is unhappy name, because it
initialize variable to
Hi
2017-06-19 5:55 GMT+02:00 Pavel Stehule :
>
>
> 2017-06-17 7:58 GMT+02:00 Fabien COELHO :
>
>>
>> I have not any other comments. The implementation is trivial. I rerun all
>>> tests and tests passed.
>>>
>>> I'll mark this patch as ready for commiters.
>>>
>>
>> Oops, I just noticed a stupid c
On Tue, 30 May 2017 at 05:30 Christoph Berg wrote:
> Oh interesting, I didn't know about pager_min_lines. That sounds
> useful as well. +1 on the analogous pager_min_cols option.
>
On closer inspection, I note that psql already has a 'columns' \pset
option, which does control the width for trigg
On Fri, Mar 24, 2017 at 7:10 AM, Rushabh Lathia
wrote:
> While looking at the code around tab-complete.c, I
> found the ordering in words_after_create array is not
> correct for DEFAULT PRIVILEGES, which been added
> under below commit:
>
> commit d7d77f3825122bde55be9e06f6c4851028b99795
> Author:
2017-06-17 7:58 GMT+02:00 Fabien COELHO :
>
> I have not any other comments. The implementation is trivial. I rerun all
>> tests and tests passed.
>>
>> I'll mark this patch as ready for commiters.
>>
>
> Oops, I just noticed a stupid confusion on my part which got through, I
> was setting "ERROR"
I have not any other comments. The implementation is trivial. I rerun all
tests and tests passed.
I'll mark this patch as ready for commiters.
Oops, I just noticed a stupid confusion on my part which got through, I
was setting "ERROR" as "success", inverting the expected boolean value.
Her
Re: Jeff Janes 2017-05-29
> > Usually I turn the pager off completely, and only switch it on when I am
> > about to execute something that will return many rows, but what I'd really
> > like is some way to tell psql to activate the pager as normal for height,
> > but to ignore width. My first th
On Sun, May 28, 2017 at 10:09 PM, Brendan Jurd wrote:
> Hello hackers,
>
> I am often frustrated by the default behaviour of the psql pager, which
> will activate a pager if the output is deemed to be "too wide" for the
> terminal, regardless of the number of lines output, and of the
> pager_min_
Hello hackers,
I am often frustrated by the default behaviour of the psql pager, which
will activate a pager if the output is deemed to be "too wide" for the
terminal, regardless of the number of lines output, and of the
pager_min_lines setting.
This behaviour is sometimes desirable, but in my us
Hello Pavel,
I have not any other comments. The implementation is trivial. [...]
Indeed.
I'll mark this patch as ready for commiters.
Thanks for the review.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
2017-05-22 21:33 GMT+02:00 Fabien COELHO :
>
> Please find attached a v2 which hopefully takes into account all your
>>> points above.
>>>
>>> Open question: should it gather more PQerrorResultField, or the two
>>> selected one are enough? If more, which should be included?
>>>
>>
>>
>> I don't th
Please find attached a v2 which hopefully takes into account all your
points above.
Open question: should it gather more PQerrorResultField, or the two
selected one are enough? If more, which should be included?
I don't think so it is necessary. No in this moment. ERROR_CODE and
ERROR_MESSAG
2017-05-22 9:40 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> After some discussions about what could be useful since psql scripts now
accepts tests, this patch sets a few variables which can be used by psql
after a "front door" (i.e. actually typed by the user) query:
- RESU
Hello Pavel,
After some discussions about what could be useful since psql scripts now
accepts tests, this patch sets a few variables which can be used by psql
after a "front door" (i.e. actually typed by the user) query:
- RESULT_STATUS: the status of the query
- ERROR: whether the query fai
Hi
2017-04-04 23:01 GMT+02:00 Pavel Stehule :
>
>
> 2017-04-04 22:05 GMT+02:00 Fabien COELHO :
>
>>
>> After some discussions about what could be useful since psql scripts now
>> accepts tests, this patch sets a few variables which can be used by psql
>> after a "front door" (i.e. actually typed
2017-04-04 22:05 GMT+02:00 Fabien COELHO :
>
> After some discussions about what could be useful since psql scripts now
> accepts tests, this patch sets a few variables which can be used by psql
> after a "front door" (i.e. actually typed by the user) query:
>
> - RESULT_STATUS: the status of the
After some discussions about what could be useful since psql scripts now
accepts tests, this patch sets a few variables which can be used by psql
after a "front door" (i.e. actually typed by the user) query:
- RESULT_STATUS: the status of the query
- ERROR: whether the query failed
- ERROR
Hi All,
While looking at the code around tab-complete.c, I
found the ordering in words_after_create array is not
correct for DEFAULT PRIVILEGES, which been added
under below commit:
commit d7d77f3825122bde55be9e06f6c4851028b99795
Author: Peter Eisentraut
Date: Thu Mar 16 18:54:28 2017 -0400
On Mon, Feb 13, 2017 at 3:40 PM, Fabien COELHO wrote:
> What would be the mnemonic for "," an "@"?
Oh, I just picked it because control-@ is the nul character, and your
commands would be nullified. I realize that's pretty weak, but we're
talking about finding a punctuation mark to represent the
1 - 100 of 1797 matches
Mail list logo
