| From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
|---|---|
| To: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
| Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Brian E Gallew <geek+(at)cmu(dot)edu>, PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org> |
| Subject: | Re: [HACKERS] psql and libpq fixes |
| Date: | 2000-02-10 16:55:00 |
| Message-ID: | 200002101655.LAA10981@candle.pha.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
>
I think we would have to have more need for multi-word setttings than
this one before adding that complexity.
--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Lockhart | 2000-02-10 17:00:57 | Re: [HACKERS] psql and libpq fixes |
| Previous Message | Tom Lane | 2000-02-10 16:48:15 | Solution for LIMIT cost estimation |