"Marko Kreen" <[EMAIL PROTECTED]> writes:
> On 10/3/08, Gregory Stark <[EMAIL PROTECTED]> wrote:
>> The other reason I thought of this is that if EDB or anyone else uses forks
>> for a private purpose then it would avoid the whole issue of conflicts. The
>> best option right now would be to set aside a range of values for private
>> purposes.
> Good idea.
No, it isn't, because the patch assumes that the set of possible fork
numbers is pretty compact (grep for uses of MAX_FORKNUM).
I don't believe for a moment that EDB, or anyone else competent enough
to put in a private fork definition, can't manage to add it to enum
ForkNumber. They'd probably be well advised to operate with a private
setting of catversion anyway, which would ensure that installations
using this private fork wouldn't interoperate with backends not knowing
about it. Once you've done that there's no need to worry about
conflicts.
I have no particular objection to the .fsm idea though --- that could be
implemented fairly simply with a lookup table while forming the file name.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
