Thread: safe to overload objectSubId for a type?

Hi,

I don't mean "overload objectSubId" in any ObjectAddress that PG code
would ever see. I am only thinking of a data structure of my own that
is ObjectAddress-like and has all three components available all the
time, and for an object that's a type, I would find it handy to stash
a typmod there, and not have to carry those around separately.

As far as I can tell, most objects (maybe all, except attributes
and attribute defaults?) have the objectSubId unused. But I would not
want to paint myself into a corner if anyone anticipates making
objectSubId mean something for type objects somewhere down the road.

Thanks,
-Chap

Chapman Flack <chap@anastigmatix.net> writes:
> I don't mean "overload objectSubId" in any ObjectAddress that PG code
> would ever see. I am only thinking of a data structure of my own that
> is ObjectAddress-like and has all three components available all the
> time, and for an object that's a type, I would find it handy to stash
> a typmod there, and not have to carry those around separately.

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.

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.  So I'd be pretty down
on allowing it to mean typmod instead.

            regards, tom lane

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

Chapman Flack <chap@anastigmatix.net> writes:
> On 09/02/19 00:29, Tom Lane wrote:
>> 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?

Hm, apparently we already do handle that in some way, because
this works:

regression=# create type myenum as enum ('red', 'black');
CREATE TYPE
regression=# create type mycomposite as (f1 int, f2 myenum, f3 text);
CREATE TYPE
regression=# drop type myenum;
ERROR:  cannot drop type myenum because other objects depend on it
DETAIL:  column f2 of composite type mycomposite depends on type myenum
HINT:  Use DROP ... CASCADE to drop the dependent objects too.
regression=# drop type myenum cascade;
NOTICE:  drop cascades to column f2 of composite type mycomposite
DROP TYPE
regression=# \d mycomposite
        Composite type "public.mycomposite"
 Column |  Type   | Collation | Nullable | Default 
--------+---------+-----------+----------+---------
 f1     | integer |           |          | 
 f3     | text    |           |          | 

I'm too lazy to go check, but I suspect that the representation
of this situation in pg_depend makes use of a dependency for a
column of the relation associated with the mycomposite type,
so that the entry having nonzero objsubid has classid pg_class
not classid pg_type.

Nonetheless, I'd be pretty hesitant to allow somebody to use
objsubid with some entirely different meaning for types.  That
seems certain to lead to confusion and bugs.

            regards, tom lane

On 09/02/19 11:41, Tom Lane wrote:
> Hm, apparently we already do handle that in some way, because
> this works:
> ...
> Nonetheless, I'd be pretty hesitant to allow somebody to use
> objsubid with some entirely different meaning for types.

As long as it stays an internal detail of a caching scheme used by me
and will be masked back to 0 before anything escapes to elsewhere, so it
really only exploits the current fact that objSubId for types carries
no information at all ... and no one seems to be chiming in with a pressing
case for changing that ... I think I can get away with the simple scheme,
admitting the possibility of having to revisit it down the road.

Regards,
-Chap