2010/8/7 David E. Wheeler <da...@kineticode.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 > > > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
