Andres Freund <and...@anarazel.de> writes:
> On 2018-07-26 14:06:16 -0400, Tom Lane wrote:
>> I was about to add Andrew's example as a test case (also shown in
>> attached), but realized that there's a problem: just as noted in
>> the similar test for named-composite-type changes a bit above there,
>> the failure fails to fail in CLOBBER_CACHE_ALWAYS builds. We'd decided
>> to just omit that test (cf feb1cc559) but having been embarrassed by
>> this crash I'm feeling like we really could do with some test coverage.
>> I'm tempted to extract the affected test cases into their own small
>> test script and provide two variant expected files, one for normal and
>> one for CLOBBER_CACHE_ALWAYS builds. Thoughts?
> Could we perhaps avoid the divergence by prevent a replan, e.g. by using
> a cursor and starting the execution of the query before changing the
> type? Otherwise I think I'm ok with having an alternative file, as long
> as there's a good comment explaining it.
Well, at the moment the point of having a test would be to ensure that the
code fails cleanly (without crashing) after a type change. AFAICS your
proposal would amount to not really testing the type-change path at all,
so I don't think it helps.
I was envisioning a file header comment along the lines of
-- Cache-behavior-dependent test cases
--
-- These tests logically belong in plpgsql_record.sql, and perhaps someday
-- can be moved back there. For now, however, their results are different
-- between regular and CLOBBER_CACHE_ALWAYS builds, so we must have two
-- expected-output files to cover both cases. To minimize the maintenance
-- effort resulting from that, this file should contain only tests that
-- do have different results under CLOBBER_CACHE_ALWAYS.
regards, tom lane
