On Aug 6, 2010, at 10:49 PM, Pavel Stehule wrote:
>> Huh? You can select into an array:
>
> and pg doesn't handle 2D arrays well - can't to use ARRAY(subselect)
> constructor for 2D arrays
Right.
>> try=# select ARRAY(SELECT ARRAY[k,v] FROM foo);
>> ERROR: could not find array type for datatype text[]
>
> try SELECT ARRAY(SELECT row(k,v) FROM foo)
Yeah, but those aren't nested arrays., They're…well, they're ordered pairs. ;-P
> sure, but it isn't relevant here - the problem is buildin output
> functions for datatypes. For example - true is different formated in
> PostgresSQL and different formated in xml or JSON. Date values are
> differently formated in JSON and XML. So if you would to correctly
> format some date type value and if your interface is only text - then
> you have to cast value back to binary and format it again. More - if
> you have a information about original data type, you can use a corect
> format. So if you use a only text parameters, then you lost a
> significant information (when some parameter are not text). For
> example, if I have only text interface for some hypothetical JSON API,
> then I am not able to show a boolean value correctly - because it
> doesn't use a quoting - and it is string and isn't number.
Point. FWIW, though, this is already an issue for non-SQL functions. PL/Perl,
for example, gets all arguments cast to text, AFAICT:
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.
> There is some other issue - PLpgSQL can't to work well with untyped
> collections. But it isn't problem for C custom functions, and there
> are not any reason why we can't to support polymorphic collections
> (+/- because these collection cannot be accessed from PLpgSQL
> directly).
I completely agree with you here. I'd love to be able to support RECORD
arguments to non-C functions.
>> I agree that it's not as sugary as pairs would be. But I admit to having no
>> problem with
>>
>> SELECT foo(ARRAY[ ['foo', 'bar'], ['baz', 'yow']]);
>>
>> But maybe I'm biased, since there's a lot of that sort of syntax in pgTAP..
>>
>
> Yes, when you are a author of code, you know what you are wrote. But
> when you have do some review? Then an reviewer have to look on
> definition of foo, and he has to verify, if you are use a parameters
> well. For two params I don't see on first view what system you used -
> [[key,key],[value,value]] or [[key,value],[key, value]]. More you have
> to use a nested data structure - what is less readable then variadic
> parameters. And - in pg - you are lost information about original data
> types.
Valid points. I agree that it would be nicer to use RECORDs:
SELECT foo( row('foo', 1), row('bar', true));
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?
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
