Re: [HACKERS] psql and libpq fixes - Mailing list pgsql-hackers

From Thomas Lockhart
Subject Re: [HACKERS] psql and libpq fixes
Date
Msg-id 38A2EEC9.F9A79E23@alumni.caltech.edu
Whole thread Raw
In response to Re: [HACKERS] psql and libpq fixes  (Peter Eisentraut <e99re41@DoCS.UU.SE>)
Responses Re: [HACKERS] psql and libpq fixes
Re: [HACKERS] psql and libpq fixes
Re: [HACKERS] psql and libpq fixes
List pgsql-hackers
> > > FYI, the commands are
> > > \set EXIT_ON_ERROR
> > > and
> > > \unset EXIT_ON_ERROR
> > > It's a normal psql variable, but incidentally the syntax seems kind of
> > > easy to remember.
> > Can we change that to the more standard ON_ERROR_STOP?

Any chance of multi-word options? Like "\set on error stop"?

And at least part of the reason other systems can do some error
recovery is that they decouple the parser from the backend, so the
parser is carried closer to the client, and the client can be more
certain about what is being done. But that carries a lot of baggage
too...

If/when we do get more decoupling, it might be done through a Corba
interface, which would allow us to get away from the string-based
client/server protocol, and will handle typing, marshalling, byte
ordering, etc more-or-less transparently.
                - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Solution for LIMIT cost estimation
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] psql and libpq fixes