Re: GUC and postgresql.conf docs
От | Tom Lane |
---|---|
Тема | Re: GUC and postgresql.conf docs |
Дата | |
Msg-id | 16750.1052847054@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: GUC and postgresql.conf docs (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: GUC and postgresql.conf docs
|
Список | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.net> writes: > Do we need to communicate the server encoding during any part of the > protocol? Probably. What if the client needs to know what is the set of characters that can actually be stored in the database? client_encoding doesn't tell you the whole truth on that. I'm also still unconvinced that binary data I/O should perform encoding conversion (it does as of CVS tip, but I'm not 100% sold that that's the right choice). > But the server encoding can already be fetched inside an SQL session from > the official source. ... if you know where to look for it, and if you know that you are not currently in an aborted transaction, and probably a few other "if's". > A read-only parameter to make this information > available in a different way just seems wasteful. It is duplicative to a certain extent, but the point is to make life easier for client libraries. See past discussions with Barry Lind in particular. The general mechanism seems necessary in any case, and once we have it, applying it to these particular values isn't adding much bloat. regards, tom lane
В списке pgsql-hackers по дате отправления: