From: | hubert depesz lubaczewski <depesz(at)depesz(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Hamid Akhtar <hamid(dot)akhtar(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16171: Potential malformed JSON in explain output |
Date: | 2020-02-03 11:40:22 |
Message-ID: | 20200203114022.GA29777@depesz.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Sun, Feb 02, 2020 at 11:48:32AM -0500, Tom Lane wrote:
> > Does that prevent backpatching this, or are we Ok with EXPLAIN text output not
> > being stable across minors? AFAICT Pg::Explain still works fine with this
> > change, but mileage may vary for other parsers.
> I'm not sure about that either. It should be a clear win for parsers
> of the non-text formats, because now we're generating valid
> JSON-or-whatever where we were not before. But it's not too hard to
> imagine that someone's ad-hoc parser of text output would break,
> depending on how much it relies on field order rather than indentation
> to make sense of things.
Change looks reasonable to me.
Interestingly Pg::Explain doesn't handle either current JSON output in
this case (as it's not a valid JSON), nor the new one - but this can be
fixed easily.
Best regards,
depesz
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2020-02-03 12:54:22 | Re: ERROR: subtransaction logged without previous top-level txn record |
Previous Message | PG Bug reporting form | 2020-02-03 10:38:10 | BUG #16240: The now() function is populating different date time than expected |
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2020-02-03 12:40:48 | Re: Add %x to PROMPT1 and PROMPT2 |
Previous Message | Amit Kapila | 2020-02-03 11:03:22 | Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager |