Re: Out arguments name of "pg_identify_object_as_address" function in 9.5.14 and 11beta3

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jean-Pierre Pelletier <jean(dot)pierre(dot)pelletier0(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Out arguments name of "pg_identify_object_as_address" function in 9.5.14 and 11beta3
Date: 2018-09-03 18:36:31
Message-ID: 6649.1535999791@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jean-Pierre Pelletier <jean(dot)pierre(dot)pelletier0(at)gmail(dot)com> writes:
> Two of the out arguments name of function
> "pg_identify_object_as_address" are not as documented.
> Documentation says "name" and "args", but function returns
> "object_names" and "object_args".

Hm, yeah. The documentation of pg_get_object_address() seems
equally divorced from reality. What's more, while pg_get_object_address
and pg_identify_object_as_address agree on the naming of the
internal-representation arguments (classid,objid,objsubid),
they don't agree on the naming of the other arguments
(type,name,args vs. type,object_names,object_args). Somebody
was being pretty inconsistent there.

I do not think we can change the names of the output arguments;
it'd break existing queries. However, renaming input arguments
shouldn't affect anything. So I propose we make pg_get_object_address'
input arguments be named type,object_names,object_args for
consistency with the other function, and update the docs to match.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-09-03 18:42:31 Re: Caching query plan costs
Previous Message Bruce Momjian 2018-09-03 18:33:35 Re: Caching query plan costs