Skip site navigation (1) Skip section navigation (2)

Re: data to json enhancements

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: data to json enhancements
Date: 2012-09-28 12:22:51
Message-ID: 5065969B.40008@gmx.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On 9/27/12 10:36 AM, Tom Lane wrote:
> (1) Reject Robert's assumption that we have to support both
> interpretations for every cast situation.  For instance, it doesn't
> seem that unreasonable to me to insist that you have to cast to text
> and then to json if you want the literal-reinterpretation behavior.
> The main problem then is figuring out a convenient way to provide
> interpretation #2 for text itself.

I don't think it's going to work to special-case text like that.  For
one thing, it would mean wildly different things would happen depending
on whether text or varchar is used.

> (2) Add another hidden argument to cast functions, or perhaps repurpose
> one of the ones that exist now.  This is likely to come out rather ugly
> because of the need to shoehorn it into an API that's already suffered
> a couple of rounds of after-the-fact additions, but it's certainly
> possible in principle.

Could there be a case where you'd want to be able to serialize a type to
JSON like that, but don't actually want a regular cast to exist (even
explicit)?

> The main thing I'd want is to not define it
> in a JSON-only fashion --- so the first thing is to be able to explain
> the distinction we're trying to make in a type-independent way.

There is XML, which would use the same mechanism.  For example, we
currently have a cast from text to xml, which interprets the text as an
XML document.  The other interpretation would escape <, >, etc.

> (3) Invent an auxiliary type along the lines of "json_value" and say
> that you create a cast from foo to json_value when you want one
> interpretation, or directly to json if you want the other.  Then
> things like record_to_json would look for the appropriate type of cast.
> This is a bit ugly because the auxiliary type has no reason to live
> other than to separate the two kinds of cast, but it avoids creating
> any new JSON-specific mechanisms in the type system.

What if some wanted to create a yaml type as an extension.  How would
they associate yaml and yaml_value?



In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2012-09-28 13:03:13
Subject: Re: data to json enhancements
Previous:From: Hannu KrosingDate: 2012-09-28 10:22:12
Subject: Re: data to json enhancements

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group