Re: Allowing extensions to find out the OIDs of their member objects

Hi,

On 2019-01-20 18:50:33 -0500, Tom Lane wrote:
> In [1] I propose that we should allow extensions to get their hands
> on the ability to transform function calls as per "protransform" and
> to generate lossy index quals based on items in WHERE clauses. The
> APIs to give an extension control at the right points seem pretty
> straightforward, but there's a problem standing in the way of actually
> doing anything useful once you've got control. In order to either
> analyze a passed-in clause or generate a new one, the extension will
> need to know the OIDs of the functions/operators it's working with.
> And extension objects don't have fixed OIDs.

Why does it need to know all its oids, rather than just the one of the
operation protransform is called for? Am I missing something? And if
so, why isn't it sufficient to just pass in that oid along with the
node?

> A larger issue is whether "hand out some OIDs on-demand" is a
> sustainable strategy. I think that it is, if we encourage extensions
> to assign fixed OIDs only to objects they really need to. In thirty-ish
> years of core PG development, we've only used up ~4200 fixed OIDs,
> and a lot of those are for functions that probably don't really need
> fixed OIDs but got one because we give one to every built-in function.
> However, if there's a big land rush to claim large chunks of OIDs,
> we might have a problem.

I'm not sure that "30 years" argument holds that much power - we've
surely reused oids. And core PG is going to be much more conservative
than any sort of external user.

Which range are you thinking of handing out here? We use oid ranges as
proxy for system-object-ness in a number of places, so we can't really
just hand out ones below FirstNormalObjectId. And we can't really hand
out any above that, because there'd be conflicts - even if we increased
FirstNormalObjectId today, there'd be issues with pg_upgrade.

Greetings,

Andres Freund