| From: | "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de> |
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Ryan Pedela <rpedela(at)datalanche(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, hlinnaka(at)iki(dot)fi, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: [PATCH] Generalized JSON output functions |
| Date: | 2015-07-12 18:11:48 |
| Message-ID: | CACACo5TwSi+X7Nxo7_qhkJO3MuBMgt8rYFWKaENtYYdZkiLuOw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > we talking about output - I can imagine, so there is only two
possibilities
> > - plain join, and pretty formatted join (but with only one style).
>
> This makes sense. Postgres core really only needs to support the
> minimum styles necessary for core requirements. This means raw
> unformatted json for data productions to client and an appropriate
> formatting for explain. Fancier stuff like a generic formatted is
> fine but those features *belong in an extension*.
The thing is - it's not only about whitespace, otherwise I would probably
not bother with the generic interface. For my original problem, there is
simply no way to do this correctly in an extension w/o copying over all of
the logic from json.c, which I have to do right now, would rather not.
Alex
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2015-07-12 18:39:08 | Re: [PATCH] Generalized JSON output functions |
| Previous Message | Tom Lane | 2015-07-12 17:50:51 | Re: TABLESAMPLE doesn't actually satisfy the SQL spec, does it? |