On Fri, 2012-05-04 at 15:59 -0400, Robert Haas wrote: > On Fri, May 4, 2012 at 3:49 PM, Hannu Krosing <ha...@krosing.net> wrote: > > On Fri, 2012-05-04 at 09:52 -0400, Tom Lane wrote: > >> Hannu Krosing <ha...@2ndquadrant.com> writes: > >> > On Wed, 2012-05-02 at 12:06 -0700, Andrew Dunstan wrote: > >> >> So given that do we do anything about this now, or wait till 9.3? > >> > >> > I'd like the json support in 9.2 updated as follows > >> > >> I think it's too late to be entertaining proposals for such changes in > >> 9.2. If we had concluded that the existing functions were actively > >> wrong or a bad idea, > > > > I think that hard-coding "postgresql text" representation as our json > > representation without a possibility for the user tio easily fix it > > without rewriting foll xx_to_json() functions is borderline "actively > > wrong". > > > > Can we at least have the xxx_to_json() functions try cast to json first > > and fall back to text if the cast fails. > > I think the idea that you can involve the casting machinery in this is > misguided. sometextval::json has got to mean that sometextval is > expected to be in the form of a syntactically correct JSON value - and > NOT that we wrap it in a JSON string. We can have constructors for > JSON, but they've got to be separate from the casting machinery.
on the contrary - the string representation of textual value a is "a" casting should _not_ neam syntax check, casting is by definition a conversion. if we cast text to int, we return value of type int , if we cast int to numeric(5,2) we return value of type numeric(5,2) why should casring to json work differntly ? > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers