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 9:48 PM, Pavel Stehule wrote:
>
>>> That's exactly what my solution does. The array solution doesn't. Whether it's appropriate to use a custom composite type, however, is an open question.
>>
>> no it doesn't - in your design there are no different notation for key
>> and for value. Next this design block  a '->'. Because it's based on
>> polymorphic operator. But it can be a one variant - where you would to
>> put together expr with expr. And you can't do more from user space
>> now. But if you have a build in operator for (sqlidentifier, any) with
>> early processing - like "AS" in xml_attributies, we can do it. The
>> using of this operator can be limited only on function parameter
>> context.
>
> I'm sorry, I still don't follow. It creates an ordered pair, with one value being named "key" and the other one "val". And when you use the ~> operator, the lhs is the key and the rhs if the value.
>
>> Postgres has a array of rows (Inside C or plperlu can be transofmed to
>> real hash simply). It just miss a user friendly notation for using it.
>
> I think Tom's right, frankly: An array of arrays will be the best solution for your interface. Sure someone could include more than two items in each nested array, or fewer than 2, but if there are more you ignore them, and if there are fewer you treat them as NULLs.

it can be a just plain text - it isn't about functionality, it is
about readability, verbosity and stored procedures developer's comfort
- and some consistency.

Pavel

>
> Best,
>
> David
>
>
>