Re: Renaming conversion procs (was Re: [GENERAL] Error on compile for Windows)

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Renaming conversion procs (was Re: [GENERAL] Error on compile for Windows)
Дата
Msg-id 9837222c0911021041u12b355b9o9d8c8b5f374c0eb5@mail.gmail.com
обсуждение исходный текст
Ответ на Renaming conversion procs (was Re: [GENERAL] Error on compile for Windows)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Renaming conversion procs (was Re: [GENERAL] Error on compile for Windows)
Список pgsql-hackers
On Mon, Nov 2, 2009 at 18:54, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Steve Atkins <steve@blighty.com> writes:
>> I've also seen it with winzip. Again, ISTR that the exact limits were
>> obscure but that restricting the path to less than 100 characters
>> avoided any problems.
>
> Hmm.  It strikes me that the names seen by tar include "postgresql-x.y.z/".
> The only file paths that approach 100 characters on that basis as of
> 8.4.1 are
>
> postgresql-8.4.1/src/backend/utils/mb/conversion_procs/utf8_and_shift_jis_2004/utf8_and_shift_jis_2004.c
> postgresql-8.4.1/src/backend/utils/mb/conversion_procs/utf8_and_euc_jis_2004/utf8_and_euc_jis_2004.c
>
postgresql-8.4.1/src/backend/utils/mb/conversion_procs/euc_jis_2004_and_shift_jis_2004/euc_jis_2004_and_shift_jis_2004.c
>
> The first and third of these have in fact been reported as trouble
> spots.  AFAIR the second has not, but it's exactly 100 characters, which
> would explain why it works ... or will work till we get to two digits in
> the minor release number, anyway :-(.  So that seems to validate your
> theory.
>
> If we want to set an upper limit of 100 characters, and allow for
> release numbers up to 99.99.99, then the maximum length for
> conversion_procs file names would be 19 characters (plus .c), and the
> same for their directories.  So we could rename these to, say,
>        utf8_and_sjis2004
>        utf8_and_euc2004
>        euc2004_sjis2004
> This would be an easy change to make going forward (other than loss of
> CVS history, but I'm not terribly worried about that for these files).
> We could not so easily back-patch it because the .so filenames are
> already embedded in installations' pg_proc tables.  Personally I'd
> be satisfied if it's fixed for 8.5 and beyond --- comments?

Seems like this would be a major PITA for packagers and end-user. And
it would be an issue for the vast majority of our users - who use
binary packages on whatever platform they're on. And that only to help
those that have a broken (or severely limited) tar version, *and* try
to build from source.

Thus, +1 for doing this for 8.5 and beyond only.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: operator exclusion constraints
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: Some notes about Param handling with "Oracle style" plpgsql variables