Re: [HACKERS] psql \d sequence display

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

Re: [HACKERS] psql \d sequence display

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

Re: [HACKERS] psql - add ability to test whether a variable exists

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:

Re: [HACKERS] psql - add ability to test whether a variable exists

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

Re: [HACKERS] psql - add ability to test whether a variable exists

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

Re: [HACKERS] psql - add ability to test whether a variable exists

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.

Re: [HACKERS] psql - add ability to test whether a variable exists

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

Re: [HACKERS] psql - add ability to test whether a variable exists

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

Re: [HACKERS] psql - add ability to test whether a variable exists

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

Re: [HACKERS] psql: new help related to variables are not too readable

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.

Re: [HACKERS] psql: new help related to variables are not too readable

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

Re: [HACKERS] psql: new help related to variables are not too readable

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

Re: [HACKERS] psql: new help related to variables are not too readable

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 >

Re: [HACKERS] psql: new help related to variables are not too readable

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 >

Re: [HACKERS] psql: new help related to variables are not too readable

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

Re: [HACKERS] psql: new help related to variables are not too readable

"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

Re: [HACKERS] psql: new help related to variables are not too readable

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

Re: [HACKERS] psql: new help related to variables are not too readable

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

Re: [HACKERS] psql: new help related to variables are not too readable

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

Re: [HACKERS] psql: new help related to variables are not too readable

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

Re: [HACKERS] psql: new help related to variables are not too readable

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

Re: [HACKERS] psql: new help related to variables are not too readable

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql: new help related to variables are not too readable

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

Re: [HACKERS] psql: new help related to variables are not too readable

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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,

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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.

Re: [HACKERS] psql - add special variable to reflect the last query status

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 >

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql: new help related to variables are not too readable

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

Re: [HACKERS] psql: new help related to variables are not too readable

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

Re: [HACKERS] psql: new help related to variables are not too readable

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

Re: [HACKERS] psql: new help related to variables are not too readable

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

Re: [HACKERS] psql: new help related to variables are not too readable

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

Re: [HACKERS] psql: new help related to variables are not too readable

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. > >

Re: [HACKERS] psql: new help related to variables are not too readable

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

Re: [HACKERS] psql: new help related to variables are not too readable

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

Re: [HACKERS] psql: new help related to variables are not too readable

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql - add special variable to reflect the last query status

* 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

Re: [HACKERS] psql - add special variable to reflect the last query status

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 > &

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql --batch

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

Re: [HACKERS] psql --batch

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

Re: [HACKERS] psql --batch

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

Re: [HACKERS] psql --batch

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,

Re: [HACKERS] psql --batch

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.

Re: [HACKERS] psql --batch

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

Re: [HACKERS] psql --batch

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

Re: [HACKERS] psql --batch

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? >> >

Re: [HACKERS] psql --batch

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. >> >>

Re: [HACKERS] psql --batch

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

Re: [HACKERS] psql - add ability to test whether a variable exists

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:

Re: [HACKERS] psql - add ability to test whether a variable exists

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}

Re: [HACKERS] psql - add ability to test whether a variable exists

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

Re: [HACKERS] psql - add ability to test whether a variable exists

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

Re: [HACKERS] psql - add ability to test whether a variable exists

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

Re: [HACKERS] psql - add ability to test whether a variable exists

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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 >> + { >> +

Re: [HACKERS] psql - add special variable to reflect the last query status

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"); + } +}

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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 >>

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql: Activate pager only for height, not width

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

Re: [HACKERS] [psql] patch to fix ordering in words_after_create array

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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.

Re: [HACKERS] psql: Activate pager only for height, not width

Re: Jeff Janes 2017-05-29

Re: [HACKERS] psql: Activate pager only for height, not width

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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:

Re: [HACKERS] psql - add special variable to reflect the last query status

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?

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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)

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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

Re: [HACKERS] psql - add special variable to reflect the last query status

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: > > -

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

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

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

For two states: * for being executed (beware, it is ***important***) It does lend importance, but that's also the line continuation marker for "comment". Would that be a problem? Argh. Indeed, even if people seldom type C comments in psql interactive mode... Remaining ASCII characters

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

> > @in't gonna execute it? >> > > Hmmm... This is too much of an Americanism, IMHO. The @ looks like a handwritten 'a'. @in't gonna => ain't gonna => will not. It's a bad joke, made as a way of saying that I also could not think of a good mnemonic for '@' or ','. > I'm here all week, try the

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

Hello Corey, If I can find some simple mnemonic for "," vs "@" for being executed vs ignored, I could live with that, but nothing obvious comes to my mind. @in't gonna execute it? Hmmm... This is too much of an Americanism, IMHO. I'm here all week, try the veal. Sorry, syntax error,

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Mon, Feb 13, 2017 at 3:40 PM, Fabien COELHO wrote: > > Hello Robert, > > [...] I think we should try to make this REALLY simple. We don't really >> want to have everybody have to change their PROMPT1 and PROMPT2 strings for >> this one feature. >> > > Ok. I think that we

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Mon, Feb 13, 2017 at 11:29 AM, Robert Haas wrote: > possible states here. Just when you've figured out what tfzffft I agree with what you've said, but wanted to point out that any condition that follows a 'z' would itself be 'z'. Not that tfz is much better.

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

Hello Robert, [...] I think we should try to make this REALLY simple. We don't really want to have everybody have to change their PROMPT1 and PROMPT2 strings for this one feature. Ok. I think that we agree that the stack was too much details. How about just introducing a new value for

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Sat, Feb 11, 2017 at 2:43 AM, Fabien COELHO wrote: >> Ok, so that's not just PROMPT_READY, that's every prompt...which might be >> ok. ? is a great optional cue, and you're thinking on 2 levels deep, 2nd >> level always being '.'? > > Yep. The idea is to keep it short, but

  1   2   3   4   5   6   7   8   9   10   >