Re: [HACKERS] strange code in array_in
On Sat, 2011-10-29 at 15:13 -0400, Tom Lane wrote: > What other lookups? I just meant anything after that point in the function would surely fail (get_type_io_data). > array_out, and I believe a bunch of other places, use the same trick. OK. In retrospect it is a very simple trick, but at the time I was slightly confused by it. I guess I just haven't seen that idiom before. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] strange code in array_in
Jeff Davis 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] strange code in array_in
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. 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. Can someone please explain, and perhaps include a comment indicating what's going on? Or is it just too early and I missed something simple? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers