Re: JSON for PG 9.2
От | Simon Riggs |
---|---|
Тема | Re: JSON for PG 9.2 |
Дата | |
Msg-id | CA+U5nMJm+u8ddJExSQAPPDuZxRJ3OHs01y-i7kUrSX868g1Zww@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: JSON for PG 9.2 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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
В списке pgsql-hackers по дате отправления: