On Tue, Dec 13, 2011 at 5:22 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> On 12/12/2011 03:54 PM, Robert Haas wrote:
>>> There are way too many places that assume that the typmod can
>>> just be discarded. I don't think that's going to fly, because
>>> =(text,text) probably has different semantics from =(json,json).
>
>> And certain places where they are not allowed at all, I think (unless I
>> am misremembering the early debates about enum types and output functions).
>
> Yeah. The current system design assumes that typmod specifies a
> constraint of some sort. It is not possible to use it to change the
> semantics of the datatype. The most obvious way in which this is true
> is that selection of which operators and functions to apply to values
> does not consider typmod of the values. This is not something we should
> lightly revisit. We don't even have a handle on how to make domains
> behave differently from their underlying datatypes, and those *do* have
> their own type OIDs. Injecting typmod into the algorithm seems like a
> disaster from here.
I'm glad I didn't think of doing that before then.
Can we agree some wording to put into the docs? Sounds like some clear
warnings are needed.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
