Prev: Some notes about Param handling with "Oracle style" plpgsql variables
Next: Segfault in PL/Python
From: Magnus Hagander on 2 Nov 2009 13:41
On Mon, Nov 2, 2009 at 18:54, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> Steve Atkins <steve(a)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/

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 2 Nov 2009 14:43
Magnus Hagander <magnus(a)hagander.net> writes:
> On Mon, Nov 2, 2009 at 18:54, Tom Lane <tgl(a)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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: Some notes about Param handling with "Oracle style" plpgsql variables
Next: Segfault in PL/Python