Re: Changing max size of attribute names.

Поиск
Список
Период
Сортировка
От Benjamin Scherrey
Тема Re: Changing max size of attribute names.
Дата
Msg-id GBKGVQC8FGDGE629Z76JEJE5E0YX.3dc611b1@BONZO
обсуждение исходный текст
Ответ на Re: Changing max size of attribute names.  (Doug McNaught <doug@mcnaught.org>)
Список 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 по дате отправления:

Предыдущее
От: Mike Diehl
Дата:
Сообщение: Problem w/ date calculation.
Следующее
От: Mike Howard
Дата:
Сообщение: Turning off information messages