Re: [HACKERS] psql and libpq fixes

Поиск
Список
Период
Сортировка
От Thomas Lockhart
Тема Re: [HACKERS] psql and libpq fixes
Дата
Msg-id 38A2EEC9.F9A79E23@alumni.caltech.edu
обсуждение исходный текст
Ответ на Re: [HACKERS] psql and libpq fixes  (Peter Eisentraut <e99re41@DoCS.UU.SE>)
Ответы Re: [HACKERS] psql and libpq fixes  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: [HACKERS] psql and libpq fixes  (Peter Eisentraut <e99re41@DoCS.UU.SE>)
Re: [HACKERS] psql and libpq fixes  (Peter Eisentraut <peter_e@gmx.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Solution for LIMIT cost estimation
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] psql and libpq fixes