Re: safe to overload objectSubId for a type?

On 09/02/19 00:29, Tom Lane wrote:

> If this is totally independent of ObjectAddress, why are you even
> asking? I assume that what you mean is you'd like these values to
> bleed into ObjectAddresses or vice versa.

Only that I'm working on a data structure of my own to cache my own
representations for objects, which I can find by a simple hash lookup
on a key of three ints, given an ObjectAddress. But I'd like to have
distinct instances representing distinct typmods of a type, and if I
had a method to look up a type instance given an ObjectAddress and
typmod, and that method could simply use the typmod (or a trivially
transformed version, -1 <-> 0) as the third int of the key, then my
single hash structure and one lookup serves for everything.

Otherwise, I essentially need a second whole layer of the same machinery
to track typmod-variants of types (and forget them when unreferenced,
invalidated, yada yada), or variable-length cache keys so type keys
are four ints instead of three, or four-int keys for everything, just
because types.

Any of those alternatives would just be a SMOP if truly necessary,
but uglier and more complex.

> If we ever do make ObjectAddress.objectSubId mean something for types,
> I'd expect --- based on the precedent of relation columns --- that it'd
> specify a column number for a column of a composite type. There are
> fairly obvious use-cases for that, such as allowing a DROP of a column
> type to not propagate to the whole composite type.

Could you give an illustration to make sure I'm following? I tried to
create my own example with:

CREATE TYPE foo AS (bar int, baz int);
CREATE TABLE quux (a foo);
INSERT INTO quux (a.bar, a.baz) VALUES (12, 34);
SELECT * FROM quux;
a
---------
(12,34)
ALTER TYPE foo DROP ATTRIBUTE baz;
SELECT * FROM quux;
a
------
(12)

but I guess that must not exercise the case you had in mind.

I could say my main reason for asking was to judge the imminence of
any change. If there's a vague conceivable possibility of objectSubId
meaning something for types in the indefinite future, I might do my
simple implementation now, and some uglier SMOP alternative later
when/if needed. If somebody has such a change in mind for the near
term, that'd be different.

Regards,
-Chap