Stephen, thanks for the comments. Stephen Frost wrote:
> I don't really care for how all the get_object_address stuff uses lists > for arguments instead of using straight-forward arguments, but it's how > it's been done and I can kind of see the reasoning behind it. I'm not > following why you're switching this case (get_object_address_type) to > using a ListCell though..? The reason for changing get_object_address_type is that it's a helper soubroutine to get_object_address and we can do whatever is more convenient. It turns out that it's more convenient, for the amop/amproc cases, to pass a ListCell instead of a List. get_object_address gets its stuff directly from the parser in some cases, or from pg_get_object_address otherwise, which constructs things to mimick exactly what the parser does. We can change what the parser emits and as long as we keep get_object_address in agreement, there is no issue. There might be code churn of course (because some of those object representations travel from the parser through other parts of the backend), but that doesn't really matter much. We have now exposed that interface through the SQL-callable pg_get_object_address function, but I'm pretty sure we could change that easily and it wouldn't be a tremendous problem -- as long as we do it before 9.5 is released. For instance we might want to decide that we want to have three lists instead of two; or two lists and a numeric quantity (which would also help the large object case, currently a bit ugly), or that we want something akin to what the parser does to types using struct TypeName for opclass-related objects. Anyway I'm not hot on changing anything here. It's a bit cumbersome an interface to use, but it's not excessively exposed to the user unless they use event triggers, and even then it is perfectly reliable anyhow. > 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. Great, thanks. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers