Re: [BUGS] ltree::text not immutable?
От | Tom Lane |
---|---|
Тема | Re: [BUGS] ltree::text not immutable? |
Дата | |
Msg-id | 13790.1414094087@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [BUGS] ltree::text not immutable? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUGS] ltree::text not immutable?
|
Список | 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
В списке pgsql-hackers по дате отправления: