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

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?

            regards, tom lane

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/

Magnus Hagander <magnus@hagander.net> writes:
> On Mon, Nov 2, 2009 at 18:54, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> [ rename some conversion libraries to shorten source path names ]

> Seems like this would be a major PITA for packagers and end-user.

If we actually wanted to back-patch it, I think the least painful way
would be to tweak the Makefiles to install the built .so's under the old
names in existing release branches.  Then it would be a PITA only to the
developers ;-).  I don't personally feel it's worth it, even so.  There
are not that many people trying to build from source with weird tools.

            regards, tom lane