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 |