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?
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
