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 по дате отправления:

Предыдущее
От: "Vadim B. Mikheev"
Дата:
Сообщение: Re: [HACKERS] \dt and disk access
Следующее
От: "Dorte Munk-Jakobsen"
Дата:
Сообщение: [HACKERS] New date/time formats