Re: Invalid YAML output from EXPLAIN
От | Robert Haas |
---|---|
Тема | Re: Invalid YAML output from EXPLAIN |
Дата | |
Msg-id | AANLkTikhqkoh2TToIfZfqJgomix-2DUcHjMu-azU7fhL@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Invalid YAML output from EXPLAIN (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-bugs |
On Wed, Jun 9, 2010 at 12:58 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Jun 9, 2010 at 12:57 PM, Dean Rasheed <dean.a.rasheed@gmail.com> = wrote: >> On 9 June 2010 17:52, Robert Haas <robertmhaas@gmail.com> wrote: >>> On Wed, Jun 9, 2010 at 12:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>> Robert Haas <robertmhaas@gmail.com> writes: >>>>> On Wed, Jun 9, 2010 at 11:14 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>>>> Why not? =A0Surely we can restrict EXPLAIN's set of key names to be = safe. >>>> >>>>> It seems to me that it would be easy for a future patch to break this >>>>> by accident. >>>> >>>> Really? =A0What likely key names would be in need of quoting? =A0I can= 't >>>> imagine accepting a field name that contains punctuation or leading >>>> or trailing whitespace, for example. >>> >>> It seemed to me, in particular, that someone might use a # symbol, >>> like "# of Iterations". >>> >> >> Then the resulting XML tagname would be invalid too >> I think they would soon realise/be told that it was a bad idea. > > Hmm, you're right. =A0Maybe we should go with your approach, then. After thinking about this further, I think I'd still like to take one more crack at fixing this without quoting absolutely everything. I argued against this feature, but we decided to take it, and it seems that one of the major arguments that is being put forward is that it will be more readable than JSON, because it will have less punctuation. While the idea of optimizing a machine-readable format for human-readability doesn't typically carry much water around here, it's really the only use case for having this particular feature at all, so, if we're not going to rip it out, ISTM we ought to respect what it's there for. I would be more than willing to agree that if one more attempt isn't sufficient to fix the problem then we'll either quote everything, or rip the whole thing out. --=20 Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-bugs по дате отправления: