ltree::text not immutable?

[Tom Lane]

Seems like casting ltree to text and the subtree function should be
immutable?

Hm, yeah, I can see no reason why ltree_in and ltree_out shouldn't be
immutable. They surely ought not be volatile, which is the way they
are marked (by default) right now. The other types in the ltree
module have the same disease.

More generally, it seems like we ought to have a test in the type_sanity
regression script that checks that type I/O functions aren't volatile,
because there are various embedded assumptions that this is so, cf
commits aab353a60b95aadc00f81da0c6d99bde696c4b75 and
3db6524fe63f0598dcb2b307bb422bc126f2b15d.

That wouldn't have directly caught this problem because we don't apply
type_sanity or opr_sanity to contrib modules, only to core functions.
I have done that manually in the past and think I'll go do it again
to see what else crawls out ... but I wonder if anyone can think of
a way to automate that?

Meanwhile, as far as fixing the immediate issue goes, I propose just
fixing the misdeclarations in ltree--1.0.sql without going through all
the pushups of making an ltree--1.1.sql. In the past we've fixed
similar errors without a catversion bump on the grounds that the
implications weren't large enough to justify a catversion bump.
I think the equivalent conclusion here is we don't need an extension
version bump.

regards, tom lane

[Tom Lane]

Post by Tom Lane
More generally, it seems like we ought to have a test in the type_sanity
regression script that checks that type I/O functions aren't volatile,
because there are various embedded assumptions that this is so, cf
commits aab353a60b95aadc00f81da0c6d99bde696c4b75 and
3db6524fe63f0598dcb2b307bb422bc126f2b15d.
That wouldn't have directly caught this problem because we don't apply
type_sanity or opr_sanity to contrib modules, only to core functions.
I have done that manually in the past and think I'll go do it again
to see what else crawls out ... but I wonder if anyone can think of
a way to automate that?

Actually, the right thing to do if we want to enforce this is for
CREATE TYPE to check the marking. We'd still need a type_sanity
test to check erroneous declarations of built-in types, but a complaint
in CREATE TYPE would cover all the contrib modules as well as third-party
code.

I wouldn't propose back-patching such an error check, but it seems
reasonable to add it for 9.5. Any objections?

regards, tom lane