Re: GUC and postgresql.conf docs - Mailing list pgsql-hackers

From Tom Lane
Subject Re: GUC and postgresql.conf docs
Date
Msg-id 16750.1052847054@sss.pgh.pa.us
Whole thread Raw
In response to Re: GUC and postgresql.conf docs  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: GUC and postgresql.conf docs  (Peter Eisentraut <peter_e@gmx.net>)
List 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 by date:

Previous
From: "scott.marlowe"
Date:
Subject: Re: Scheduled jobs
Next
From: Josh Berkus
Date:
Subject: Re: Scheduled Jobs