Re: get_object_address support for additional object types

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: get_object_address support for additional object types
Date: 2015-03-12 18:48:25
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Stephen Frost wrote:

> I thought the rest of it looked alright. I agree it's a bit odd how the
> opfamily is handled but I agree with your assessment that there's not
> much better we can do with this object representation.

Actually, on second thought I revisited this and changed the
representation for opfamilies and opclasses: instead of putting the AM
name in objargs, we can put it as the first element of objname instead.
That way, objargs is unused for opfamilies and opclasses, and we're free
to use it for the type arguments in amops and amprocs. This makes the
lists consistent for the four cases: in objname, amname first, then
qualified opclass/opfamily name. For amop/amproc, the member number
follows. Objargs is unused in opclass/opfamily, and it's a two-element
list of types in amop/amproc.

The attached patch changes the grammar to comply with the above, and
adds the necessary get_object_address and getObjectIdentityParts support
code for amop/amproc objects.

The only thing a bit unusual is that in does_not_exist_skipping() we
need to do an list_copy_tail() to strip out the amname before reporting
the "skipping" message, for DROP OPERATOR CLASS/FAMILY IF NOT EXISTS.
I don't think this is a problem. In return, the code to deconstruct
amop and amproc addresses is more sensible.

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
0001-Support-opfamily-members-in-get_object_address.patch text/x-diff 33.9 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2015-03-12 19:43:51 Re: pg_rewind in contrib
Previous Message Tom Lane 2015-03-12 18:19:43 Re: Documentation of bt_page_items()'s ctid field