From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: strange code in array_in |
Date: | 2011-10-29 19:13:00 |
Message-ID: | 18898.1319915580@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> In array_in(), I see the following code:
> my_extra->element_type = ~element_type;
> It seems like it was explicitly changed from InvalidOid to
> ~element_type. At first I thought it was a mistake, but then I thought
> maybe it was to ensure that the next branch was taken even if
> element_type == InvalidOid.
Exactly.
> But the rest of the lookups will surely fail
> on InvalidOid, and it seems like it would be easy to test for InvalidOid
> at the beginning if we wanted to fail.
What other lookups? We do need to protect ourselves against
element_type being InvalidOid, and the problem is that if we just set
my_extra->element_type to InvalidOid and press on, the lookup won't be
made and we'll do something bizarre (possibly even crash) using bogus
cached information. On the other hand, element_type *shouldn't* be
InvalidOid here, so adding an explicit test for that seemed like a waste
of code. It's sufficient to let get_type_io_data complain about the
case.
array_out, and I believe a bunch of other places, use the same trick.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-10-29 19:35:27 | Re: [v9.2] make_greater_string() does not return a string in some cases |
Previous Message | Erik Rijkers | 2011-10-29 19:12:22 |