This is extracted from the DDL deparse series. These patches add
get_object_address support for the following object types:
- user mappings
- default ACLs
- operators and functions of operator families
In each case I had to create a new value in ObjectType. These object
types can not be created from the parser, which is why they don't exist
yet. But if we want to be able to process DDL for them, then we need to
cope at this level. This is the kind of fix we need to handle the
failures related to commit a486841eb11517e.
There is one strange thing in the last one, which is that an opfamily
member is represented in two arrays like this (objname, objargs):
{opfamily identity, access method identity, number} , {left type, right type}
This is a bit odd considering that operator families themselves are
addressed like this instead:
{opfamily identity} , {access method identity}
Note that the AM name is originally in objargs and moves to objnames.
The reason I did it this way is that the objargs elements can be
processed completely as an array of TypeName, and therefore there's no
need for an extra strange case in pg_get_object_address. But it does
mean that there is some code that knows to search the strategy or
function number in a specific position in the objname array.
If we had more freedom on general object representation I'm sure we
could do better, but it's what we have. I don't think it's a tremendous
problem, considering that get_object_address gets a fairly ad-hoc
representation for each object type anyway, as each gets constructed by
the grammar.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services