Re: [HACKERS] psql and libpq fixes
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] psql and libpq fixes |
Дата | |
Msg-id | Pine.GSO.4.02A.10002101817550.19049-100000@Zebra.DoCS.UU.SE обсуждение исходный текст |
Ответ на | Re: [HACKERS] psql and libpq fixes (Thomas Lockhart <lockhart@alumni.caltech.edu>) |
Список | pgsql-hackers |
On Thu, 10 Feb 2000, Thomas Lockhart wrote: > > > > 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"? Actually, that command would set "on" to the value of "errorstop". \set doesn't have any hard-coded parsing rules, like the SQL look-a-similar, it just sets variables. They can carry configuration information (like the above), application state (LASTOID), or whatever you want (\set foo `date %Y` \\ insert into mytbl values (:foo);). Kind of like a shell or Tcl, I think. > 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. At that point we may choose to write a completely new client. ;) -- Peter Eisentraut Sernanders vaeg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
В списке pgsql-hackers по дате отправления: