| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Geoghegan <pg(at)heroku(dot)com> |
| Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Similar to csvlog but not really, json logs? |
| Date: | 2014-08-27 02:47:43 |
| Message-ID: | 17319.1409107663@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Geoghegan <pg(at)heroku(dot)com> writes:
> I think that it would be a good beginner's project to make pprint()
> print JSON.
There's something to be said for that (or, really, for any standardized
widely-popular textual data format; but JSON is a perfectly reasonable
candidate).
> The existing infrastructure is user visible because of GUCs like
> debug_print_parse.
There is that :-(. The fact that these strings are stored in the catalogs
isn't a problem as long as we make the change in a major version upgrade.
But to the extent that there is client-side code that expects to make
sense of the strings, it could be a problem. Is there any such code?
If so, are we really beholden to not break it? It's not like we don't
change those data representations routinely anyway ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2014-08-27 03:00:43 | Re: Similar to csvlog but not really, json logs? |
| Previous Message | Peter Eisentraut | 2014-08-27 02:45:40 | Re: minor config doc update |