Re: pgsql: Add relation fork support to pg_relation_size() function.

Heikki Linnakangas wrote:
> 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.

Windows used to have a problem with this, but none of the versions we're
even remotely close to supporting has an issue with it. And if Windows
now manages to deal with it, I doubt others have problems with it :-)

There may be (at least on Windows) GUI tools that don't deal with it
properly, but if you point one of those at your data directory you
deserve what you get :-P (All the ones builtin to the system work)

//Magnus