Re: Small omission in type_sanity.sql

Hi,

On 2023-01-27 20:39:04 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > Tom, is there a reason we run the various sanity tests early-ish in the
> > schedule? It does seem to reduce their effectiveness a bit...
>
> Originally, those tests were mainly needed to sanity-check the
> hand-maintained initial catalog data, so it made sense to run them
> early.

It's also kinda useful to have some basic validity testing early on, because
if there's something wrong with the catalog values, it'll cause lots of issues
later.

> > Problems:
> > - "Cross-check against pg_type entry" is far too strict about legal combinations
> > of typstorage
>
> Perhaps, but it's enforcing policy about what we want in the
> initial catalog data, not what is possible to support.

True in generaly, but I don't think it matters much in this specific case. We
don't gain much by forbidding 'e' -> 'x' mismatches, given that we allow 'x'
-> 'p'.

There's a lot more such cases in opr_sanity. There's a lot of tests in it that
only make sense for validating the initial catalog contents. It might be
useful to run a more lenient version of it later though.

> So there's a bit of divergence of goals here too. Maybe we need to split up
> the tests into initial-data-only tests (run early) and tests that should
> hold for user-created objects too (run late)?

Yea, I think so. A bit worried about the duplication that might require.

But the *sanity tests also do also encode a lot of good cross-checks, that are
somewhat easy to break in code (and / or have been broken in the past), so I
think it's worth pursuing.

Greetings,

Andres Freund