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

From Peter Eisentraut
Subject Re: GUC and postgresql.conf docs
Date
Msg-id Pine.LNX.4.44.0305131739050.1617-100000@peter.localdomain
Whole thread Raw
In response to Re: GUC and postgresql.conf docs  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: GUC and postgresql.conf docs  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane writes:

> This is now in the same class as server_version, i.e., it's a read-only
> GUC variable.  I did it that way so that these values could be
> transmitted to the frontend via the new 3.0 protocol's ParameterStatus
> mechanism.

Do we need to communicate the server encoding during any part of the
protocol?  ISTM that the server encoding shouldn't ever be needed by a
client for computation, except out of pure interest.

> For instance, isn't "show lc_collate" a lot better than having to run
> pg_controldata to find out the database locale?

No, because you would like to be able to see it inside an SQL session.
But the server encoding can already be fetched inside an SQL session from
the official source.  A read-only parameter to make this information
available in a different way just seems wasteful.  We don't have read-only
parameters for any of the other columns in pg_database either.

-- 
Peter Eisentraut   peter_e@gmx.net



pgsql-hackers by date:

Previous
From: Rod Taylor
Date:
Subject: Re: Scheduled jobs
Next
From: Josh Berkus
Date:
Subject: Re: GUC and postgresql.conf docs