Re: the case for machine-readable error fields
От | Andrew Dunstan |
---|---|
Тема | Re: the case for machine-readable error fields |
Дата | |
Msg-id | 4A78CA7B.1060509@dunslane.net обсуждение исходный текст |
Ответ на | Re: the case for machine-readable error fields (David Fetter <david@fetter.org>) |
Ответы |
Re: the case for machine-readable error fields
|
Список | pgsql-hackers |
David Fetter wrote: > On Tue, Aug 04, 2009 at 10:06:37PM -0000, Greg Sabino Mullane wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: RIPEMD160 >> >> >> >>> If that's what we're trying to solve, I don't think that adding >>> some kind of proprietary shorthand coding is a good idea. If >>> we're do to this at all, it should be a connection-based GUC >>> option, and use some standard formal like XML fragments. >>> >> +1 to this idea in general, but *please* don't consider the use of >> XML. If we really need some sort of formatting, let's do CSV. Or >> YAML. Or JSON. Anything but XML. >> > > +1 on the "anything but XML." XML reeks of inner platform effect. > > <http://en.wikipedia.org/wiki/Inner-platform_effect> > > > So, we are just trying to whip into shape explain diagnostics which are in JSON or XML, and now you want us to exclude XML from this one because you don't like it? Can we please try for some consistency? Sorry to break it to you, but there are plenty of people and businesses who want XML. And I certainly don't want to have to master every data representation model out there. XML has far more traction than anything else that's comparable in my experience. The fact that Greg is prepared to suggest CSV, with its obvious serious deficiencies, as being *better* than XML, makes his whole argument highly suspect IMNSHO. cheers andrew
В списке pgsql-hackers по дате отправления: