Re: Initial review of xslt with no limits patch

2010/8/7 David E. Wheeler <david(at)kineticode(dot)com>:
> 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.
>

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.

>> 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));

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. 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[])

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)

Regards

Pavel

>
> Best,
>
> David
>
>
>
>
>
>
>
>
>
>
>