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

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Steve Atkins <steve(at)blighty(dot)com>, pgsql-hackers(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org
Subject: Re: Renaming conversion procs (was Re: Error on compile for Windows)
Date: 2009-11-02 18:41:58
Message-ID: 9837222c0911021041u12b355b9o9d8c8b5f374c0eb5@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Mon, Nov 2, 2009 at 18:54, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Steve Atkins <steve(at)blighty(dot)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/

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message John DeSoi 2009-11-02 19:01:11 Re: Cancelling Requests Frontend/Backend Protocol TCP/IP
Previous Message Tom Lane 2009-11-02 17:54:32 Renaming conversion procs (was Re: Error on compile for Windows)

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2009-11-02 19:05:23 Re: Some notes about Param handling with "Oracle style" plpgsql variables
Previous Message Simon Riggs 2009-11-02 18:28:09 Re: operator exclusion constraints