Re: Changing max size of attribute names. - Mailing list pgsql-general

From Benjamin Scherrey
Subject Re: Changing max size of attribute names.
Date
Msg-id GBKGVQC8FGDGE629Z76JEJE5E0YX.3dc611b1@BONZO
Whole thread Raw
In response to Re: Changing max size of attribute names.  (Doug McNaught <doug@mcnaught.org>)
List pgsql-general
11/1/2002 2:10:07 PM, Doug McNaught <doug@mcnaught.org> wrote:
>NAMEDATALEN is compiled into the code.  The client is going to have
>to install a custom-compiled Postgres binary.  The manual text (it
>could be clearer, I think) means that a database *installation*
>created with one value of NAMEDATALEN cannot be used with server
>binaries that have a different value.

Thanx very much for the informative and helpfule reply. Yes - the comments in the header are
indeed misleading....

>
>I *think* NAMEDATALEN was bumped up to 64 for 7.3 (now in beta) so
>they won't have to run a custom compile once 7.3 comes out if they're
>willing to upgrade.

I d/l 7.3b3 this weekend and confirmed that NAMEDATALEN is now 64.

>
>For now, they are either going to have to recompile their PG binaries
>and initdb/dump/reload, or install your hacked version on a
>nonstandard port alongside their existing installation.

7.3b3 seems to be running quite well for me. We're scheduled to deliver to the client next Sunday
and it is my plan to go ahead and convert them completely to 7.3b3 unless I run into problems.
They have a few databases in place that are 7.1 which would have to be converted if we deployed
a custom 7.2 build regardless. Is it fairly safe to assume that databases running under 7.3b3 will not
have to be reloaded when 7.3 goes into final release? Also, is there an expected timeframe for the
7.3 release yet?

    many thanx &l ater,

        Ben Scherrey



pgsql-general by date:

Previous
From: Mike Diehl
Date:
Subject: Problem w/ date calculation.
Next
From: Mike Howard
Date:
Subject: Turning off information messages