Re: Composite Types and Function Parameters

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Composite Types and Function Parameters
Дата
Msg-id 8487.1288048378@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Composite Types and Function Parameters  (Merlin Moncure <mmoncure@gmail.com>)
Ответы Re: Composite Types and Function Parameters  ("David E. Wheeler" <david@kineticode.com>)
Re: Composite Types and Function Parameters  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
Merlin Moncure <mmoncure@gmail.com> writes:
> probably hstore would be more appropriate for something like that.

An array is certainly completely the wrong thing if you don't intend
all the items to be the same datatype...

> You can also declare functions taking composite arrays, anyarray,
> variadic array, and variadic "any", although the latter requires
> function implementation in C to get the most out of it.

If you're willing to write in C you can already create functions that
accept type "record" (see record_out for an existence proof/coding
example).

Making plpgsql do that would be problematic though: it's not so much
the record parameter itself, as that you'd be excessively restricted
in what you can do with it.  If the column names and datatypes aren't
pretty predictable, plpgsql isn't going to be the language you want to
work in.

However, that objection doesn't hold for plperl or pltcl (and likely
not plpython, though I don't know that language enough to be sure).
So it would be a reasonable feature request to teach those PLs to
accept "record" parameters.  I think the fact that they don't stems
mostly from nobody having revisited their design since the
infrastructure that supports record_out was created.
        regards, tom lane


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

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: Composite Types and Function Parameters
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Range Types, discrete and/or continuous