Re: Doc patch, distinguish sections with an empty row in error code table - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Doc patch, distinguish sections with an empty row in error code table
Date
Msg-id CA+Tgmoa0JAhQyGnrOHve-esQXhM-92sGODF34uXFdaysJr-aDw@mail.gmail.com
Whole thread Raw
In response to Re: Doc patch, distinguish sections with an empty row in error code table  ("Karl O. Pinc" <kop@meme.com>)
Responses Re: Doc patch, distinguish sections with an empty row in error code table  ("Karl O. Pinc" <kop@meme.com>)
Re: Doc patch, distinguish sections with an empty row in error code table  ("Karl O. Pinc" <kop@meme.com>)
List pgsql-hackers
On Mon, Nov 5, 2012 at 10:41 PM, Karl O. Pinc <kop@meme.com> wrote:
> So at this point I'm out of ideas.  Unless somebody
> can chime in with a clue I'm ready to give up.

Frankly, I don't view this as enough of a problem to be worth spending
time on.  Actually, I'm not sure I view the formatting of that table
as a problem at all, but if it is a problem it's not a big enough one
to justify knocking ourselves out over it.  There are many more
substantive issues with our documentation that IMHO are more worthy of
our attention.

On the other hand, I *would* be somewhat in favor of migrating to a
less-obsolete toolchain, as suggested elsewhere on this thread, but
(a) I don't know whether XSL is the right thing and (b) I don't want
to move until we're darn sure we know what we're moving to is gonna be
an improvement, because this promises to make back-patching of
documentation fixes really annoying for many years to come, not to
mention creating lots of knock-on work for packagers.  We can't go on
forever with what we have now, I think, unless we're willing to assume
all the maintenance burden thereof.  But that takes nothing away from
the fact that migration to a new system WILL be painful, and we sure
don't want to do it twice, so we had better get it right the first
time.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Pg_upgrade speed for many tables
Next
From: Stefan
Date:
Subject: libpq