Re: pg_system_identifier()

On Tue, Sep 17, 2013 at 11:43 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Sep 17, 2013 at 10:59 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> On 2013-09-17 10:57:46 -0400, Robert Haas wrote:
>>> On Mon, Sep 16, 2013 at 1:25 AM, Satoshi Nagayasu <snaga(at)uptime(dot)jp> wrote:
>>> > How about adding new system view with new function which returns
>>> > a single pg_controldata value in text type, and using a cast for
>>> > each column in the view definition?
>>> >
>>> > CREATE VIEW pg_catalog.pg_controldata AS
>>> > SELECT pg_controldata('control_version')::integer AS control_version,
>>> > pg_controldata('catalog_version')::integer AS catalog_version,
>>> > pg_controldata('system_identifier')::bigint AS system_identifier,
>>> > ...
>>> > pg_controldata('next_xlog_file')::char(25) AS next_xlog_file,
>>> > ...
>>> > pg_controldata('encoding')::text AS encoding;
>>> >
>>> > Given that the view can work like a SRF, and it allows us to retrieve
>>> > all the values of pg_controldata with appropriate types in single
>>> > record from the view:
>>>
>>> I like this idea. I think having an easy way to get the values with
>>> the right types will be a plus. But adding a separate function for
>>> each field seems excessive, so I think this is a good compromise.
>>
>> Why not add a single function returning a composite type then? That'd at
>> least have a chance of returning consistent values for the individual
>> values that change during runtime. It would also produce proper errors
>> when you load a view using columns that don't exist anymore instead of
>> just at runtime.
>
> Hmm. Yeah, that might be better.

Nobody's objected to this design, so I think it's the way to go. But
since that's not what the patch implements, I'm marking this "Returned
with Feedback" in the CF app. Please feel free to submit an updated
patch for the next CommitFest (perhaps on a new thread with a name
more accurately reflecting the outcome of this design discussion).

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company