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 13:54:30
Message-ID: 7932.1052834070@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:
> {"server_encoding", PGC_USERSET}, &server_encoding_string,
> "SQL_ASCII", assign_server_encoding, show_server_encoding

> Do we even need this one? If you want to find out the server encoding
> (which should be rare anyway), you can select it from pg_database.

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.

I know we have a difference of opinion about the cleanliness of
read-only "variables", but I think it's a reasonable approach to take.
It certainly beats inventing a mechanism that duplicates the display
portions of GUC. For instance, isn't "show lc_collate" a lot better
than having to run pg_controldata to find out the database locale?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-05-13 14:07:02 Re: LIKE indexing proposal
Previous Message Þórhallur Hálfdánarson 2003-05-13 13:33:25 Re: Scheduled jobs

Browse pgsql-patches by date

  From Date Subject
Next Message Hannu Krosing 2003-05-13 14:11:44 Re: SQL99 CREATE TABLE ... (LIKE parent_table)
Previous Message Rod Taylor 2003-05-13 12:40:59 Re: SQL99 CREATE TABLE ... (LIKE parent_table)