Out arguments name of "pg_identify_object_as_address" function in 9.5.14 and 11beta3
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".
This query shows what the function returns:
select (pg_identify_object_as_address(classId, ObjId, objSubId)).*
from pg_depend where classId <> 0;
Thanks,
Jean-Pierre Pelletier
Jean-Pierre Pelletier <jean.pierre.pelletier0@gmail.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
"Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> I do not think we can change the names of the output arguments;
Tom> it'd break existing queries. However, renaming input arguments
Tom> shouldn't affect anything.
What about callers that might be using named-argument notation?
--
Andrew (irc:RhodiumToad)
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
"Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> I do not think we can change the names of the output arguments;
Tom> it'd break existing queries. However, renaming input arguments
Tom> shouldn't affect anything.
What about callers that might be using named-argument notation?
Oh ... hmm, that could be a problem. But do you think anybody's
likely to be using that for pg_get_object_address?
regards, tom lane
On 2018-Sep-03, Tom Lane wrote:
Jean-Pierre Pelletier <jean.pierre.pelletier0@gmail.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.
That would have been me. I think I changed opinion in the middle of
that development and forgot to revisit the parts I had already
committed.
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.
Hmm, I don't think it's possible to rename input args without breaking
working code either:
alvherre=# select * from pg_get_object_address(args := '{}', type := 'table', name := '{pg_class}');
classid │ objid │ objsubid
─────────┼───────┼──────────
1259 │ 1259 │ 0
(1 fila)
alvherre=# select * from pg_get_object_address('table', '{pg_class}', '{}');
classid │ objid │ objsubid
─────────┼───────┼──────────
1259 │ 1259 │ 0
(1 fila)
That said, I haven't heard of anyone using these functions in code yet,
so if we change it in 11 or 12 nobody is going to complain. (This code
was written to support adding tests for the feature, which in turn was
written to support DDL replication in BDR; that works, but it uses the C
interface rather than SQL, so it wouldn't be affected.)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
On 2018-Sep-03, Tom Lane wrote:
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.
Hmm, I don't think it's possible to rename input args without breaking
working code either:
Yeah, Andrew noted the same ...
That said, I haven't heard of anyone using these functions in code yet,
so if we change it in 11 or 12 nobody is going to complain.
... and that's pretty much my feeling. It seems really unlikely that
anyone's using named-argument notation for pg_get_object_address, and
even if they are, it wouldn't be very painful to change, or just not
use the notation if they need cross-branch compatibility. I think it's
more useful in the long run to make the names consistent.
Will go take care of it.
regards, tom lane
On 2018-Sep-05, Tom Lane wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
That said, I haven't heard of anyone using these functions in code yet,
so if we change it in 11 or 12 nobody is going to complain.... and that's pretty much my feeling. It seems really unlikely that
anyone's using named-argument notation for pg_get_object_address, and
even if they are, it wouldn't be very painful to change, or just not
use the notation if they need cross-branch compatibility. I think it's
more useful in the long run to make the names consistent.Will go take care of it.
Agreed, thanks. If you haven't touched the docs yet, here's the change
-- 9.5/9.6/10 need a slight adjustment from 11/master.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
docs-11.patchtext/plain; charset=us-asciiDownload
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index bb794e044f..853e5fee7c 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -17701,7 +17701,7 @@ SELECT collation for ('foo' COLLATE "de_DE");
</row>
<row>
<entry><literal><function>pg_identify_object_as_address(<parameter>catalog_id</parameter> <type>oid</type>, <parameter>object_id</parameter> <type>oid</type>, <parameter>object_sub_id</parameter> <type>integer</type>)</function></literal></entry>
- <entry><parameter>type</parameter> <type>text</type>, <parameter>name</parameter> <type>text[]</type>, <parameter>args</parameter> <type>text[]</type></entry>
+ <entry><parameter>type</parameter> <type>text</type>, <parameter>object_names</parameter> <type>text[]</type>, <parameter>object_args</parameter> <type>text[]</type></entry>
<entry>get external representation of a database object's address</entry>
</row>
<row>
@@ -17745,7 +17745,8 @@ SELECT collation for ('foo' COLLATE "de_DE");
information is independent of the current server, that is, it could be used
to identify an identically named object in another server.
<parameter>type</parameter> identifies the type of database object;
- <parameter>name</parameter> and <parameter>args</parameter> are text arrays that together
+ <parameter>object_names</parameter> and <parameter>object_args</parameter>
+ are text arrays that together
form a reference to the object. These three columns can be passed to
<function>pg_get_object_address</function> to obtain the internal address
of the object.
docs-96.patchtext/plain; charset=us-asciiDownload
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 5e95325250..7f903fa2d1 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -17016,7 +17016,7 @@ SELECT collation for ('foo' COLLATE "de_DE");
</row>
<row>
<entry><literal><function>pg_identify_object_as_address(<parameter>catalog_id</parameter> <type>oid</>, <parameter>object_id</parameter> <type>oid</>, <parameter>object_sub_id</parameter> <type>integer</>)</function></literal></entry>
- <entry><parameter>type</> <type>text</>, <parameter>name</> <type>text[]</>, <parameter>args</> <type>text[]</></entry>
+ <entry><parameter>type</> <type>text</>, <parameter>object_names</> <type>text[]</>, <parameter>object_args</> <type>text[]</></entry>
<entry>get external representation of a database object's address</entry>
</row>
<row>
@@ -17060,7 +17060,7 @@ SELECT collation for ('foo' COLLATE "de_DE");
information is independent of the current server, that is, it could be used
to identify an identically named object in another server.
<parameter>type</> identifies the type of database object;
- <parameter>name</> and <parameter>args</> are text arrays that together
+ <parameter>object_names</> and <parameter>object_args</> are text arrays that together
form a reference to the object. These three columns can be passed to
<function>pg_get_object_address</> to obtain the internal address
of the object.