Обсуждение: PG_GETARG_TEXT_PP vs PG_GETARG_TEXT_P

Поиск
Список
Период
Сортировка

PG_GETARG_TEXT_PP vs PG_GETARG_TEXT_P

От
Markur Sens
Дата:
In the “Extending SQL” chapter I see both of these forms are mentioned.

But can’t find info about when to use which one.


Re: PG_GETARG_TEXT_PP vs PG_GETARG_TEXT_P

От
Tom Lane
Дата:
Markur Sens <markursens@gmail.com> writes:
> In the “Extending SQL” chapter I see both of these forms are mentioned. 
> But can’t find info about when to use which one.

PG_GETARG_TEXT_P returns a traditional-format, 4-byte-header value.

PG_GETARG_TEXT_PP is allowed to return either that or a 1-byte-header
value, in case that's what the input is.

PG_GETARG_TEXT_PP is preferred in new code since it can avoid one
step of palloc-and-copy-the-value; the only real downside is you
have to use the appropriate macros to get the string's start address
and length.

            regards, tom lane



Re: PG_GETARG_TEXT_PP vs PG_GETARG_TEXT_P

От
Markur Sens
Дата:

> On 12 Jun 2022, at 12:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Markur Sens <markursens@gmail.com> writes:
>> In the “Extending SQL” chapter I see both of these forms are mentioned.
>> But can’t find info about when to use which one.
>
> PG_GETARG_TEXT_P returns a traditional-format, 4-byte-header value.
>
> PG_GETARG_TEXT_PP is allowed to return either that or a 1-byte-header
> value, in case that's what the input is.
>
> PG_GETARG_TEXT_PP is preferred in new code since it can avoid one
> step of palloc-and-copy-the-value; the only real downside is you
> have to use the appropriate macros to get the string's start address
> and length.
>
>             regards, tom lane

Ah Thanks. I wouldn’t have guessed that.
And I don’t see this mentioned in the header files either.

Is it worth adding a relevant comment in the documentation section?




Re: PG_GETARG_TEXT_PP vs PG_GETARG_TEXT_P

От
Tom Lane
Дата:
Markur Sens <markursens@gmail.com> writes:
> On 12 Jun 2022, at 12:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> PG_GETARG_TEXT_PP is preferred in new code since it can avoid one
>> step of palloc-and-copy-the-value; the only real downside is you
>> have to use the appropriate macros to get the string's start address
>> and length.

> Is it worth adding a relevant comment in the documentation section? 

It is documented in the source code where these macros are defined
(fmgr.h).

            regards, tom lane