Re: [PATCH] Make various variables read-only (const) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Make various variables read-only (const)
Date
Msg-id 797.1390015048@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Make various variables read-only (const)  (Oskari Saarenmaa <os@ohmu.fi>)
Responses Re: [PATCH] Make various variables read-only (const)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Oskari Saarenmaa <os@ohmu.fi> writes:
> On Sun, Dec 22, 2013 at 09:43:57PM -0500, Robert Haas wrote:
>> - Why change the API of transformRelOptions()?

> The comment was changed to reflect the new API, I modified
> transformRelOptions to only accept a single valid namespace to make things
> simpler in the calling code.  Nothing used more than one valid namespace
> anyway, and it allows us to just use a constant "toast" without having to
> create a 2 char* array with a NULL.

That may be true today, but the code was obviously designed to allow for
more than one namespace in the future.  I'm inclined to reject this part
of the patch, or at least rework it to const-ify the existing data
structure rather than editorialize on what's needed.

However, I believe this code was Alvaro's to begin with, so I'd be
interested in his opinion on how important it is for transformRelOptions
to allow more than one namespace per call.

Actually, I'm kind of wondering why the code has a concept of namespaces
at all, given the fact that it fails to store them in the resulting array.
It seems impossible to verify after the fact that an option was given with
the right namespace, so isn't the feature pretty much pointless?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Marko Tiikkaja
Date:
Subject: Re: array_length(anyarray)
Next
From: Peter Eisentraut
Date:
Subject: Re: 9.3.2 Client-only installation per docs fails creating directory.