Thread: Changing max size of attribute names.
I'm converting a database from MS-Access to a Postgres (7.2.3) backend but will be
keeping the Access front end and communicate via ODBC. Unfortunately the scope of work
does not allow me to alter attribute names within the tables and several attribute names
are longer than the default Postgres supported 32 chars as defined in
src/include/postgres_ext.h:NAMEDATALEN. There is also a note in this header that databases
with different NAMEDATALEN's cannot interoperate. This seems to imply that a single
database server can candle different databases with different NAMEDATALEN's - raising some
questions to me. To get things going I made the change to 52 chars and rebuilt Postgres -
everything seems to be working.
However, now that it is time to deploy to finished system to my client, they (and I)
have a STRONG preference not to have to deploy a custom build of Postgres if it can be
avoided. This gets to the afore mentioned questions raised by the comment in
postgres_ext.h. Can I somehow specify a NAMEDATALAN > 32 when creating a database under a
server which does not have a modified NAMEDATALEN? Would simply altering the size of the
attname attribute of the pg_attribute table to 52 accomplish the same effect for me?
I think you see where I'm going on this. I'd appreciate any advice on what it the
best way to handle this situation with as little impact on my client's Postgres server as
possible.
many thanx,
Ben Scherrey
Benjamin Scherrey <postgres@proteus-tech.com> writes: > I'm converting a database from MS-Access to a Postgres (7.2.3) > backend but will be keeping the Access front end and communicate via > ODBC. Unfortunately the scope of work does not allow me to alter > attribute names within the tables and several attribute names are > longer than the default Postgres supported 32 chars as defined in > src/include/postgres_ext.h:NAMEDATALEN. There is also a note in this > header that databases with different NAMEDATALEN's cannot > interoperate. This seems to imply that a single database server can > candle different databases with different NAMEDATALEN's - raising > some questions to me. To get things going I made the change to 52 > chars and rebuilt Postgres - everything seems to be working. 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. 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. 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. -Doug
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
Benjamin Scherrey <postgres@proteus-tech.com> writes: > 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? Unfortunately not -- beta4 will require an initdb and a reload, due to a change in the system catalog format. However, beta4 should be out very soon... > Also, is there an expected timeframe for the 7.3 release yet? When It's Ready :-) I believe RC1 is planned after beta4, so it should be fairly soon. Cheers, Neil -- Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
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