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