On Mon, Apr 19, 2021 at 11:49 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > I didn't mean to imply that it's necessarily theoretically impossible, > but given our lack of visibility into what a function or operator > will do, plus the way that the collation feature was bolted on > with minimal system-level redesign, it's sure pretty darn hard. > Code like record_eq is doing a lot at runtime that we can't really > see from static analysis.
It's worth pointing out that code like record_eq is not (or at least should not be) fundamentally unpredictable and unruly. The fact that record_eq does typecache lookups and whatnot seems to me to be an implementation detail. What record_eq is entitled to assume about collations could be formalized by some general high-level specification. It ought to be possible to do this, just as it ought to be possible for us to statically determine if a composite type is safe to use with B-Tree deduplication. Whether or not it's worth the trouble is another matter, but it might be if a single effort solved a bunch of related problems, not just the collation dependency problem. > Anyway, given the ALTER TYPE ADD ATTRIBUTE counterexample, I'm > definitely starting to lean towards "revert and try again in v15". The counterexample concerns me because it seems to indicate a lack of sophistication in how dependencies are managed with corner cases -- I don't think that it's okay to leave the behavior unspecified in a stable release. But I also think that we should consider if code like record_eq is in fact the real problem (or just the lack of any general specification that constrains code like it in useful ways, perhaps). This probably won't affect whether or not the patch gets reverted now, but it still matters. -- Peter Geoghegan
