Re: array support patch phase 1 patch
От | Tom Lane |
---|---|
Тема | Re: array support patch phase 1 patch |
Дата | |
Msg-id | 26491.1049810497@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: array support patch phase 1 patch (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-patches |
Peter Eisentraut <peter_e@gmx.net> writes: > Joe Conway writes: >> ...etc up to 6 dimensions > Why only 6? See uses of MAXDIM. If you feel that 6 isn't enough, I wouldn't have a problem with raising MAXDIM to 10 or so. I don't think it's worth trying to eliminate the limit completely; that would add palloc overhead to every array operation, for a feature people are unlikely to use. >> 4. Duplicated contrib/array functionality (and then some) in the >> backend using polymorphic functions and operators. > Couldn't this kind of operation be handled more cleanly (at least > semantically speaking), if we provide a function that converts an array to > a set and then use standard set searching operations? For example, > SELECT 2 IN TABLE(ARRAY[1,2,3]); Not sure about that. Is there any guidance in the SQL 200x spec about what they expect people to actually *do* with the ARRAY[] syntax? I'm currently working over the patch, but am not going to commit this part (yet), since I have some problems with the implementation anyway. >> 5. Side note: I added ANYARRAY1 and ANYELEMENT1 in this version. > Doing what? I'm hoping to avoid committing those, as they don't seem to be completely implemented in this patch. They may be required to represent the behavior of array_coerce() though. Not sure yet. regards, tom lane
В списке pgsql-patches по дате отправления: