2010/8/8 David E. Wheeler <da...@kineticode.com>:
> On Aug 7, 2010, at 12:24 AM, Pavel Stehule wrote:
>
>>> try=# create or replace function try(bool) returns text language plperl AS
>>> 'shift';
>>> CREATE FUNCTION
>>> Time: 121.403 ms
>>> try=# select try(true);
>>> try
>>> -----
>>> t
>>> (1 row)
>>>
>>> I wish this wasn't so.
>>>
>>
>> It must not be - it depends on PL handler implementation. PostgreSQL
>> call PL handler with binary values. I am thinking so new Python PL can
>> do it well.
>
> I'm thinking an update to PL/Perl would be useful. Frankly, I'd most like to
> see proper array support. But that's another topic.
>
>>> Valid points. I agree that it would be nicer to use RECORDs:
>>>
>>> SELECT foo( row('foo', 1), row('bar', true));
>>
>> I am not absolutly satisfied - but it's better, than arrays.
>
>>> Certainly much clearer. But given that we've gone round and round on
>>> allowing non-C functions to use ROWs and gotten nowhere, I don't know that
>>> we'll get any further now. But can you not create a C function that allows
>>> a signature of VARIADIC RECORD?
>>
>> you can do a variadic over ROW type. We have not a polymorphic arrays
>> - so isn't possible to write VARIADIC RECORD now.
>
> Ah, right. I guess table types can't be cast to RECORD?
>
>> It could be a nice
>> if we are to define a own composite types with polymorphic fields.
>> Then you can do:
>>
>> CREATE TYPE pair AS (key text, value "any");
>> CREATE FUNCTION foo(VARIADIC pair[])
>
> Yes.
>
>> other idea is leave arrays - and thinking about key, value collection
>> as new kind of data types. so maybe
>>
>> CREATE FUNCTION foo(VARIADIC params COLECTION OF text WITH UNIQUE text KEY)
>
> COLLECTION?
yes, sorry - simply - class where fields can be accessed via specified
index - unique or not unique.
>
> David
>
>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
