Re: data to json enhancements
От | Peter Eisentraut |
---|---|
Тема | Re: data to json enhancements |
Дата | |
Msg-id | 5065969B.40008@gmx.net обсуждение исходный текст |
Ответ на | Re: data to json enhancements (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: data to json enhancements
|
Список | 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?
В списке pgsql-hackers по дате отправления: