Gregory Stark <stark@enterprisedb.com> writes:
> I suppose if all we want to do is assert that constructors don't create this
> situation we could have an assertion that calls the constructor a second time
> (with palloc generating garbage data) and compares the results with
> datumEqual.
After further reflection I think it might indeed be the case that we
only have to worry about the datatype input routines, since those are
what are invoked to create Consts that the user has a right to expect
are equal().
I cons'd up a quick hack along the above lines and ran the regression
tests with it. The failures suggest that aside from array_in, we'll
need to fix these types:pathtsquerylquery (in contrib)ltree (in contrib)
That seems like a short enough list that the right fix for the back
branches is just to fix these input routines (palloc0 instead of palloc
should do it). I'm not sure yet if we want some less-klugy solution
for the future.
regards, tom lane