Re: Truncation of object names

From: Joel Burton <jburton(at)scw(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Truncation of object names
Date: 2001-04-13 21:08:46
Message-ID: Pine.LNX.4.21.0104131704040.26169-100000@olympus.scw.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 13 Apr 2001, Tom Lane wrote:

> Obviously, these objections are not strong enough to keep us from
> increasing the standard value of NAMEDATALEN if it seems that many
> people are running into the limit. But AFAICT relatively few people
> have such problems, and I'm hesitant to make everyone deal with a change
> for the benefit of a few. Count me as a weak vote for leaving it where
> it is ...

Hmm... Of course, it's Bad to break things if one doesn't have to. But
(IMHO) its also bad to leave it at a setting that makes some group of
people (~ 3%?) have to recompile it, and a larger group (~ 10%) wish they
did/knew how to. (I, in general, share your hesistancy to break something
for the benefit of the few, 'cept I'm one of the few this time. ;-) )

For some changes, one could just prewarn the world that This Is Coming,
and they should anticipate it with 6 months notice or such. In this case,
though, it would seem that knowing it was coming wouldn't help any --
you'd still have to recompile your client for the 32char names and the 64
(?) char names, during the 7.1 -> 7.2 (or 7.5 -> 8.0 or
whatever) transition period.

I'd like to see it longer -- is there any sane way of doing this with
notice, or, as I fear, would it always be a pain, regardless of how much
advance notice the world rec'd?

Thanks,
--
Joel Burton <jburton(at)scw(dot)org>
Director of Information Systems, Support Center of Washington

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Butler 2001-04-13 21:16:58 NUMERIC type benchmarks
Previous Message Nathan Myers 2001-04-13 20:59:29 Re: Truncation of object names