Re: psql: show only failed queries - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: psql: show only failed queries
Date
Msg-id CAFj8pRA3i-7NEf71WEBjqfAfEwudJzOJuUNLEdkScCzMypR1sw@mail.gmail.com
Whole thread Raw
In response to Re: psql: show only failed queries  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: psql: show only failed queries
List pgsql-hackers



2014-08-07 7:10 GMT+02:00 Fujii Masao <masao.fujii@gmail.com>:
On Thu, Aug 7, 2014 at 6:26 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> Hello
>
> updated version patch in attachment

Thanks! But ISTM you forgot to attached the patch.

grr .. I am sorry
 

>> +    /* all psql known variables are included in list by default */
>> +    for (known_varname = known_varnames; *known_varname; known_varname++)
>> +        varnames[nvars++] = pg_strdup(*known_varname);
>>
>> Don't we need to append both prefix and suffix to even known variables?
>
>
> ??? I am not sure if I understand well - probably system "read only"
> variables as DBNAME, USER, VERSION should not be there

I had that question because complete_from_variables() is also called by the
tab-completion of "\echo :" and it shows half-baked variables list. So
I thought probably we need to change complete_from_variables() more to
fix the problem.

I understand now.

I fixed it.

I have a question.\echo probably should not to show empty known variable.

data for autocomplete for \echo should be same as result of "\set"

 

>> +    else if (strcmp(prev2_wd, "\\set") == 0)
>> +    {
>> +        if (strcmp(prev_wd, "AUTOCOMMIT") == 0)
>>
>> ISTM that some psql variables like IGNOREEOF are not there. Why not?
>
>
> yes, there are not complete for DBNAME, ENCODING, FETCH_COUNT, HISTCONTROL,
> HISTFILE, HISTSIZE, HOST, IGNOREEOFF, PROMPT*,USER,  VERSION
>
> There are more reasons:
>
> * paremeter is not a enum (string, number or both): FETCH_COUNT, PROMPT,
> HISTSIZE, ..
>
> * variable is pseudo read only  - change has not any effect: DBNAME,
> ENCODING, VERSION

So HISTCONTROL should be there because it doesn't have such reasons at all?


yes

Pavel
 
Regards,

--
Fujii Masao

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fixed redundant i18n strings in json
Next
From: Peter Geoghegan
Date:
Subject: Re: B-Tree support function number 3 (strxfrm() optimization)