Re: SQL99 ARRAY support proposal
От | Joe Conway |
---|---|
Тема | Re: SQL99 ARRAY support proposal |
Дата | |
Msg-id | 3E6CBCDC.10005@joeconway.com обсуждение исходный текст |
Ответ на | Re: SQL99 ARRAY support proposal (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: SQL99 ARRAY support proposal
|
Список | pgsql-hackers |
Tom Lane wrote: > But I think I like better the notion of extending my bound-together- > ANYARRAY-and-ANYELEMENT proposal, > http://archives.postgresql.org/pgsql-hackers/2003-03/msg00319.php > > Suppose that we do that, and then further say that ANYARRAY or > ANYELEMENT appearing as the return type implies that the return type > is actually the common element or array type. Then we have such > useful behaviors as: > > array_push(anyarray, anyelement) returns anyarray > array_pop(anyarray) returns anyelement > array_subscript(anyarray, int) yields anyelement > singleton_array(anyelement) yields anyarray > > The last three cases cannot be handled by a SAMEASPARAM construct. That was my concern also. I like the above. So if I understand correctly, all instances of anyarray and anyelement in a function definition would need to be self-consistent, but the group could represent essentially any datatype with its corresponding array type. If we need more than one of these self consistent groups, we could resort to anyarray1/anyelement1, etc. Does this sound correct? Also, an implementation question: if I have a type oid for an element, what is the preferred method for determining the corresponding array? I'm thinking that the most efficient method might be to use the element-type name with a '_' prepended to get the array-type oid, but that seems ugly. Thoughts? Thanks, Joe
В списке pgsql-hackers по дате отправления: