Re: Updating psql for features of new FE/BE protocol
От | Kevin Brown |
---|---|
Тема | Re: Updating psql for features of new FE/BE protocol |
Дата | |
Msg-id | 20030626002027.GE16911@filer обсуждение исходный текст |
Ответ на | Re: Updating psql for features of new FE/BE protocol (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Updating psql for features of new FE/BE protocol
|
Список | pgsql-hackers |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I think 'is_superuser' is more appropriate. > > Okay, fine. > > I forgot one other thing that is available from the recent libpq > additions and needs to be exposed by psql: error message verbosity > setting. > > What's there now is described in > http://candle.pha.pa.us/main/writings/pgsql/sgml/libpq-control.html > to wit, "terse", "default", and "verbose" options. > > We have the choice of exposing this as a backslash command or as a > special variable in psql --- any preferences? My preference for such things is to use variables. It seems to me that backslash commands should be reserved for actual actions, e.g. "show me the list of tables" or "import data from stdin", etc. It seems to me that variables are a natural way of representing the state of psql, and that changing that state should be accomplished through the standard mechanisms, i.e. \set. > Also, I would like to provide the same set of options w.r.t. messages > logged in the server log. Here there is an additional frammish that > could be imagined, ie, more detail for more-serious errors. Any > opinions about what it should look like? Not sure exactly what you're asking for here. If you're asking what additional detail should be included for more serious errors, I'd say it should be things like the actual text of the query being executed and perhaps the file and line number of the code that threw the error. A stack trace could be useful in the most extreme cases (and, obviously, only when verbosity is maximized), too, but that may be too much to ask for. :-) -- Kevin Brown kevin@sysexperts.com
В списке pgsql-hackers по дате отправления: