Re: JSON for PG 9.2
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndQuadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, Robert Haas <robertmhaas@gmail.com>, Bruce Momjian <bruce@momjian.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-12-13T07:06:36Z
Lists: pgsql-hackers
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