Re: proposal: table functions and plpgsql

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: table functions and plpgsql
Дата
Msg-id 162867790805220636i59332ba6h976ca29c1b95e3a2@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: table functions and plpgsql  (Hannu Krosing <hannu@krosing.net>)
Список pgsql-hackers
2008/5/22 Hannu Krosing <hannu@krosing.net>:
> On Wed, 2008-05-21 at 23:06 +0200, Pavel Stehule wrote:
>> 2008/5/21 Hannu Krosing <hannu@krosing.net>:
>> > On Wed, 2008-05-21 at 13:31 -0400, Merlin Moncure wrote:
>> >> On Wed, May 21, 2008 at 1:28 PM, Hannu Krosing <hannu@krosing.net> wrote:
>> >> >> In my proposal I don't create any default variables. Result type is
>> >> >> only virtual - I don't need write it to system directory. I thing it's
>> >> >> better than using some specific predeclared type as RESULTTYPE OR
>> >> >> RESULTSET.
>> >> >
>> >> > How is this different from using OUT params and RETURNS SETOF RECORD ?
>> >>
>> >> *) you reference output variables via rowtype (r.var vs. var)
>> >
>> > As I'm currently working on updating another pl (pl/python), I'd like to
>> > know how will this affect get_call_result_type() defined in funcapi.h.
>> > will there be an extra parameter for record name there ?
>>
>> no
>
> why not ?
>
> do you think that other pl languages won't need it ?

no, I don't thing it. But I don't need to solve problem with
identifier colissions in external languages, because SQL is separated
from language. So there will not be changes for these languages.

I plan modify build_function_result_tupdesc_d function, but an changes
will not be visible from outside.

But there isn't any breaks to use this information (argmode) for pl
languages. Only I havn't any idea about it.

Regards
Pavel

>
> ---------------
> Hannu
>
>
>
>


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: idea: storing view source in system catalogs
Следующее
От: "Amit jain"
Дата:
Сообщение: Error while executing pg_dump "invalid memory alloc request size 4294967293"