Tom Lane wrote:
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.
Agreed.
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.
Yeah, I think it's a good idea nevertheless. While users don't need to poke around in the data directory, for those people who do, it's more pleasant if the files have self-explanatory names.
If we go with the ".fsm" extension, we'll get "12345.fsm.1" when the FSM grows large enough to be segmented. Does anyone have a problem with a filename with two dots? Shouldn't be a problem, I guess.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
