Re: GUC and postgresql.conf docs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: GUC and postgresql.conf docs
Date: 2003-05-13 17:30:54
Message-ID: 16750.1052847054@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message jks 2003-05-13 17:41:42 Re: fomatting an interval (resend)
Previous Message scott.marlowe 2003-05-13 16:59:46 Re: Scheduled jobs

Browse pgsql-patches by date

  From Date Subject
Next Message Manfred Koizar 2003-05-13 19:57:39 Re: [PATCHES] Static snapshot data
Previous Message Larry Rosenman 2003-05-13 16:20:26 Re: GUC and postgresql.conf docs