| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Brendan Jurd <direvus(at)gmail(dot)com> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Florian Pflug <fgp(at)phlo(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL) |
| Date: | 2013-04-04 04:11:15 |
| Message-ID: | 3529.1365048675@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Brendan Jurd <direvus(at)gmail(dot)com> writes:
> My thought was that on-disk zero-D arrays should be converted into
> empty 1-D arrays (with default lower bounds of course) when they are
> read by array_recv.
Huh? array_recv would not get applied to datums coming off of disk.
The only way to make this 100% transparent would be to go through every
C-coded function that deals with arrays and make sure it delivers
identical results for both cases. It's possible we could do that for
array functions in the core code, but what about user-written
extensions?
In any case, the whole exercise is pointless if we don't change the
visible behavior of array_dims et al. So I think the idea that this
would be without visible consequence is silly. What's up for argument
is just how much incompatibility is acceptable.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Brendan Jurd | 2013-04-04 04:54:54 | Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL) |
| Previous Message | Greg Smith | 2013-04-04 01:49:20 | Re: Page replacement algorithm in buffer cache |