| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hannu Krosing <hannu(at)2ndQuadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Subject: | Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ? |
| Date: | 2012-05-05 09:13:14 |
| Message-ID: | 1336209194.13755.10.camel@vanquo.pezone.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On fre, 2012-05-04 at 12:30 -0400, Andrew Dunstan wrote:
> Yeah, what I've been thinking about in conjunction with similar
> problems is some sort of type registry, so that we could code for
> non-builtin types in certain cases.
It certainly seems to come up a lot, but I'm not sure whether the two
main use cases -- mapping types into languages, and mapping types into
JSON (or XML, as an alternative) -- would have the same solution. A
third use case that could be included as well is changing the main text
or binary format of a type (e.g., what datestyle does). So instead of
having just a hard-coded set of typinput/typoutput, typrecv/typsend,
you'd have a catalog of
(context, inputfunc, outputfunc)
and the context would a language, something json or xml, or a
user-settable value. This could become quite complicated, but it sure
could solve a lot of issues in one go.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2012-05-05 09:16:18 | Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ? |
| Previous Message | Peter Eisentraut | 2012-05-05 09:06:15 | Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ? |