Re: [HACKERS] Array bug is still there....
От | Thomas G. Lockhart |
---|---|
Тема | Re: [HACKERS] Array bug is still there.... |
Дата | |
Msg-id | 33AFE4D0.E66AB99@jpl.nasa.gov обсуждение исходный текст |
Ответ на | [HACKERS] Array bug is still there.... (Andrew Martin <martin@biochemistry.ucl.ac.uk>) |
Список | pgsql-hackers |
Andrew Martin wrote: > Just run the regression tests on 6.1 and as I suspected the array bug > is still there. The regression test passes because the expected output > has been fixed to the *wrong* output. OK, I think I understand the current array behavior, which is apparently different than the behavior for v1.0x. Postgres v6.1 allows one to specify a dimensionality for an array object when declaring that object/column. However, that specification is not used when decoding a field. Instead, the dimensionality is deduced from the input string itself. The dimensionality is stored with each field, and is used to encode the array on output. So, one is currently allowed to mix array dimensions within a column, but Postgres seems to keep that all straight for input and output. Is this the behavior that we want? Just because it is different from previous behavior doesn't mean that it is undesirable. However, when mixing dimensionality within the same column it must be more difficult to figure out how to do comparison and other operations on arrays. If we are to enforce dimensionality within columns, then I need to figure out how to get that information from the table declaration when decoding fields. Bruce, do you know where to look for that kind of code? Anyone have an idea on how much this code has changed over the last year?? - Tom --ELM913966242-1523-0_ --ELM913966242-1523-0_--
В списке pgsql-hackers по дате отправления: