Re: ltree::text not immutable?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Van Dyk <joe(at)tanga(dot)com>
Cc: "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ltree::text not immutable?
Date: 2014-10-23 19:54:47
Message-ID: 13790.1414094087@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

I wrote:
> 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Heikki Linnakangas 2014-10-24 10:52:48 Re: BUG #11749: range_in, range_out dosn't work
Previous Message Tom Lane 2014-10-23 19:31:44 Re: ltree::text not immutable?

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2014-10-23 23:23:02 Re: superuser() shortcuts
Previous Message Brightwell, Adam 2014-10-23 19:52:18 Re: superuser() shortcuts