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
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? |
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 |