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?
