Re: BUG #5748: Invalid oidvector data during binary recv
От | Tom Lane |
---|---|
Тема | Re: BUG #5748: Invalid oidvector data during binary recv |
Дата | |
Msg-id | 16032.1289839906@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #5748: Invalid oidvector data during binary recv (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #5748: Invalid oidvector data during binary recv
|
Список | pgsql-bugs |
I wrote: > Yeb Havinga <yebhavinga@gmail.com> writes: >> Binary send and recv of the value at hand would change it into a 0-D vector. > The reason for that is that in general we don't make a distinction > between zero-size arrays of different dimensions. Actually, after consuming a bit more caffeine, I see what Yeb is on about. Even though the system in general doesn't make much of a distinction between zero-element arrays of different dimensionalities, there *are* functions that can distinguish --- array_ndims() being the most obvious one. Shouldn't we ensure that binary dump and reload of an array value doesn't change the value in any SQL-observable way? If so, I think his patch is correct, even though it's changing more than just the originally-complained-of behavior. While I'm looking at this ... why is it that array_ndims returns NULL and not 0 for a zero-dimensional array? 0-D arrays might have been unsupported at one time, but they're certainly considered valid now. regards, tom lane
В списке pgsql-bugs по дате отправления: