Thomas Munro <thomas.mu...@gmail.com> writes:
> ... The question
> on my mind is whether reverting the feature and trying again for 15
> could produce anything fundamentally better at a design level, or
> would just fix problems in the analyser code that we could fix right
> now.
Well, as I said, I think what we ought to do is treat any record-accepting
functions/operators as "don't know, better assume it's collation
dependent". What's not clear to me is how that concept could be
shoehorned into the existing design.
> For example, if you think there actually is a potential better
> plan than using pg_depend for this, that'd definitely be good to know
> about.
I really dislike using pg_depend, for a couple of reasons:
* You've broken the invariant that dependencies on pinned objects
are never recorded. Now, some of them exist, for reasons having
nothing to do with the primary goals of pg_depend. If that's not
a sign of bad relational design, I don't know what is. I didn't
look at the code, but I wonder if you didn't have to lobotomize
some error checks in dependency.c because of that. (Perhaps
some sort of special-case representation for the default
collation would help here?)
* pg_depend used to always be all-not-null. Now, most rows in it
will need a nulls bitmap, adding 8 bytes per row (on maxalign=8
hardware) to what had been fairly narrow rows. By my arithmetic
that's 13.3% bloat in what is already one of our largest
catalogs. That's quite unpleasant. (It would actually be
cheaper to store an empty-string refobjversion for non-collation
entries; a single-byte string would fit into the pad space
after deptype, adding nothing to the row width.)
> Hrmph. Yeah. We didn't consider types that change later like this,
> and handling those correctly does seem to warrant some more thought
> and work than we perhaps have time for. My first thought is that we'd
> need to teach it to trigger reanalysis.
That seems like a nonstarter, even before you think about race
conditions.
regards, tom lane
