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
