Re: proposal: alternative psql commands quit and exit - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: proposal: alternative psql commands quit and exit
Date
Msg-id 20180114004129.GM2416@tamriel.snowman.net
Whole thread Raw
In response to Re: proposal: alternative psql commands quit and exit  (Vik Fearing <vik.fearing@2ndquadrant.com>)
List pgsql-hackers
Vik,

* Vik Fearing (vik.fearing@2ndquadrant.com) wrote:
> On 01/13/2018 10:52 PM, Stephen Frost wrote:
> > * Vik Fearing (vik.fearing@2ndquadrant.com) wrote:
> >> On 01/09/2018 02:29 AM, Alvaro Herrera wrote:
> >>> Everaldo Canuto wrote:
> >>>> Change my patch will make psql different from other sql clients I use
> >>>> (sqlplus and mysql).
> >>>
> >>> Well, I don't think we're too hot about copying their behavior exactly.
> >>> This thread discussed the behavior at length and a consensus was found
> >>> after much thinking.  No one is imposing anything.
> >>>
> >>>> I am happy with my custom version of psql so you can cancel/delete/ignore
> >>>> my patch.
> >>>
> >>> We're not happy to lose a potential contributor, but of course that's
> >>> your prerogative.
> >>>
> >>> Can we find somebody else willing to implement the agreed-upon behavior?
> >>
> >> I'm currently reviewing two other patches in the commitfest (in my
> >> limited time).  When I'm done with those I would be happy to pick this
> >> up if no one else has.
> >
> > Looks like the status of this should really be 'waiting on author' (even
> > if the current author isn't really interested in updating it, sounds
> > like Vik might be), so I've adjusted its status.
> >
> > I'm also of the opinion that this would be good to have, though I don't
> > know that I'll have time to bring it over the line for v11.
>
> After re-reading the thread, I think the original patch is optimal.  I
> don't like what the consensus is and so I have no interest in
> implementing it.
>
> In particular, I currently hate how pasting a query with tabs screws
> everything up with unhelpful completions.  I don't want to add to that
> with the column example Tom exposed in [1] and especially with the
> plpgsql example Vladimir Svedov exposed in [2].

The issue expressed in [1] was pretty clearly addressed, imv, by only
printing out a message instead of actually aborting things as suggested
later by Robert.  That seem approach can be used to deal with the
plpgsql 'exit;' case mentioned in your [2].

> I quite like the idea of blanking the database name in PROMPT2 as
> suggested by Daniel in [3], I would be happy to work on that patch if
> others agree.

I'm not against that as it's largely orthogonal and seems pretty
reasonable by itself.  I don't know that having it really takes anything
away from having help/quit/exit be detected by psql and a message sent
back to the user that maybe they are looking for help.

If this is picked up by psql then we can also do things like *not* throw
the message out there when we know what we're working with is from a \ef
or similar, so this would only happen if you're actually pasting some
big function in that happens to have 'exit;' in it, and then you get a
message back, but otherwise the function definition works just fine and
you can ignore it and move on...

Maybe we should have a \pset parameter to disable this too, so that
people who really don't have to see the warnings kicked back have a way
to get rid of them.  That certainly seems like it'd be pretty simple to
do and something we could include in the help output...

Thanks!

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Vik Fearing
Date:
Subject: Re: proposal: alternative psql commands quit and exit
Next
From: Tom Lane
Date:
Subject: Re: proposal: alternative psql commands quit and exit