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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Out arguments name of "pg_identify_object_as_address" function in 9.5.14 and 11beta3
Дата
Msg-id 29730.1536162576@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Out arguments name of "pg_identify_object_as_address" functionin 9.5.14 and 11beta3  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: Out arguments name of "pg_identify_object_as_address" functionin 9.5.14 and 11beta3  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Funny hang on PostgreSQL 10 during parallel index scan on slave
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Out arguments name of "pg_identify_object_as_address" functionin 9.5.14 and 11beta3