On Mon, Nov 15, 2010 at 4:51 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
We went to a lot of effort to preserve lower bounds for dumped arrays so I would agree. I was actually one of the few people that actually ran into this prior to the fix. We had arrays generated by the intagg functions which were 0-based and after dumping and reloading were 1-based causing our functions which calculated the array sizes to misbehave. > > 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. Is this the same question as split() on enmpty strings? Do we have a problem distinguishing between a 0-dimensional array and a 1-dimensional empty array? -- greg -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
