Re: Inefficient handling of LO-restore + Patch
От | Tom Lane |
---|---|
Тема | Re: Inefficient handling of LO-restore + Patch |
Дата | |
Msg-id | 19344.1019686408@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Inefficient handling of LO-restore + Patch (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Inefficient handling of LO-restore + Patch
|
Список | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.net> writes: > Tom Lane writes: >> select compilation_options(); > This assumes that compilation options only matter in the server and that > only SQL users would be interested in them. In fact, compilation options > affect client and utility programs as well, and it's not unusual to have a > wild mix (if only unintentional). Good point. It'd be worthwhile to have some way of extracting such information from the clients as well. > IMHO, the best place to put this information is in the version output, as > in: > $ ./psql --version > psql (PostgreSQL) 7.3devel > contains support for: readline Is that sufficient? The clients probably are not affected by quite as many config options as the server, but they still have a nontrivial list. (Multibyte, SSL, Kerberos come to mind at once.) I'd not like to see us assume that a one-line output format will do the job. A way to interrogate the libpq being used by psql might be good too. regards, tom lane
В списке pgsql-hackers по дате отправления: