Re: Doc patch, distinguish sections with an empty row in error code table

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Doc patch, distinguish sections with an empty row in error code table
Дата
Msg-id CA+Tgmoa0JAhQyGnrOHve-esQXhM-92sGODF34uXFdaysJr-aDw@mail.gmail.com
обсуждение исходный текст
Ответ на 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>)
Re: Doc patch, distinguish sections with an empty row in error code table  ("Karl O. Pinc" <kop@meme.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Pg_upgrade speed for many tables
Следующее
От: Stefan
Дата:
Сообщение: libpq