On Tue, Dec 13, 2011 at 5:22 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Andrew Dunstan <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
