Re: Initial review of xslt with no limits patch - Mailing list pgsql-hackers

2010/8/7 David E. Wheeler <david@kineticode.com>:
> On Aug 6, 2010, at 10:15 PM, Pavel Stehule wrote:
>
>>> This is not exactly without precedent, either: our built-in xpath()
>>> function appears to use precisely this approach for its namespace-list
>>> argument.
>>
>> it's one variant, but isn't perfect
>>
>> a) it expects so key and value are literals
>
> 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

>
> try=# create table foo(k text, v text);
> CREATE TABLE
> try=# insert into foo values ('foo', 'bar'), ('baz', 'yow');
> INSERT 0 2
> try=# select ARRAY[k,v] FROM foo;
>   array
> -----------
>  {foo,bar}
>  {baz,yow}
> (2 rows)
>
> 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)

>
> Okay, so nested arrays are harder.
>
>> b) it expects so all values has same types - what is usually what we
>> need, but not necessary
>
> The XML interface converts them all to text anyway, no?
>

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.

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


>> c) isn't too readable - I am sorry so I am repeating - it is same
>> reason, why people will prefer a VARIADIC function before function
>> with array - but I can accept, so this is my view of world
>
> 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.

Regards

Pavel

> Best,
>
> David
>
>
>