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".
Andwhen 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
includemore than two items in each nested array, or fewer than 2, but if there are more you ignore them, and if there
arefewer you treat them as NULLs.
Best,
David