Обсуждение: configure datatype name > 31?
Hi, the name datatype, which is used at least here:
pg_database.datname
pg_shadow.usename
is a 31 character field. That seems awfully low. For instance, what if I'm
silly enough to want to make a database named:
customer_GUID
where GUID is something like:
0ff7d0cc-7394-4b15-a28e-7018b1056f9c
You can imagine I have many customers, each with their own database; since I
use a guid to distinguish the customers, it makes most sense to me to use a
guid to distinguish their databases.
Since GUIDs (in that form at least) are 36 characters, I'm already SOL. I
can condense the data, but I'd really much rather just use it like it is.
SQL Server 2000, for example, uses nvarchar(256) for the sysname field,
which seems to perform a similar function.
Is there a way to configure PostgreSQL to make the name field larger?
Thanks,
// mark
Sorry, this is a duplicate sent before I subscribed to the group--it was stalled, so I resent after subscribing. This question has been answered. Thanks, // mark > -----Original Message----- > From: pgsql-admin-owner@postgresql.org > [mailto:pgsql-admin-owner@postgresql.org]On Behalf Of Mark McEahern > Sent: Friday, May 03, 2002 10:12 AM > To: pgsql-admin@postgresql.org > Subject: [ADMIN] configure datatype name > 31? > > > Hi, the name datatype, which is used at least here: > > pg_database.datname > pg_shadow.usename > > is a 31 character field. That seems awfully low. For instance, > what if I'm > silly enough to want to make a database named: > > customer_GUID > > where GUID is something like: > > 0ff7d0cc-7394-4b15-a28e-7018b1056f9c > > You can imagine I have many customers, each with their own > database; since I > use a guid to distinguish the customers, it makes most sense to > me to use a > guid to distinguish their databases. > > Since GUIDs (in that form at least) are 36 characters, I'm already SOL. I > can condense the data, but I'd really much rather just use it like it is. > > SQL Server 2000, for example, uses nvarchar(256) for the sysname field, > which seems to perform a similar function. > > Is there a way to configure PostgreSQL to make the name field larger? > > Thanks, > > // mark > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > >
"Mark McEahern" <marklists@mceahern.com> writes:
> Tom, thanks for your reply. I am now able to create databases and users
> with longer names, but I am unable to login with the long username.
I think you're stuck on that, unless you want to be *really*
incompatible with the rest of the world. The startup packet format has
hard-wired field sizes --- see src/include/libpq/pqcomm.h:
#define SM_DATABASE 64
#define SM_USER 32
#define SM_OPTIONS 64
#define SM_UNUSED 64
#define SM_TTY 64
Don't ask me why SM_USER is different from the rest :-(
If you change these I'd strongly advise bumping the protocol minor
version number, so that you don't have weird behavior should you try
to interoperate with standard code.
This is another thing that should be on the list of stuff to fix when
we next change the FE/BE protocol ...
regards, tom lane
"Mark McEahern" <marklists@mceahern.com> writes:
> Regarding bumping the protocol number, is there documentation that describes
> exactly how to do that? I looked at the source code and nothing jumped out
> at me as the obvious spot to make this change.
I believe the right thing is to change
#define PG_PROTOCOL_LATEST PG_PROTOCOL(2,0)
to
#define PG_PROTOCOL_LATEST PG_PROTOCOL(2,1)
(or minor-number-of-your-choice) in pqcomm.h. You'd also need to change
PG_PROTOCOL_LIBPQ in libpq-int.h, and comparable changes in any other
client libraries that you'd updated.
Untested, use at your own risk, etc...
regards, tom lane
Tom Lane wrote: > "Mark McEahern" <marklists@mceahern.com> writes: > > Tom, thanks for your reply. I am now able to create databases and users > > with longer names, but I am unable to login with the long username. > > I think you're stuck on that, unless you want to be *really* > incompatible with the rest of the world. The startup packet format has > hard-wired field sizes --- see src/include/libpq/pqcomm.h: > > #define SM_DATABASE 64 > #define SM_USER 32 > #define SM_OPTIONS 64 > #define SM_UNUSED 64 > #define SM_TTY 64 > > Don't ask me why SM_USER is different from the rest :-( > > If you change these I'd strongly advise bumping the protocol minor > version number, so that you don't have weird behavior should you try > to interoperate with standard code. > > This is another thing that should be on the list of stuff to fix when > we next change the FE/BE protocol ... Comment added to source that SM_USER length should match the others. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> Don't ask me why SM_USER is different from the rest :-(
>>
>> If you change these I'd strongly advise bumping the protocol minor
>> version number, so that you don't have weird behavior should you try
>> to interoperate with standard code.
>>
>> This is another thing that should be on the list of stuff to fix when
>> we next change the FE/BE protocol ...
> Comment added to source that SM_USER length should match the others.
Actually, I had no such change in mind. IMHO the right fix is to
eliminate the fixed-width fields entirely. I see no good reason why
the startup packet shouldn't be several null-terminated strings with
no presupposed lengths. In most cases that would actually make the
packet shorter than it is now.
We'd probably want an overall sanity-check limit on the packet size,
but it could be of the order of 10K without any problem that I could
see.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> Don't ask me why SM_USER is different from the rest :-( > >> > >> If you change these I'd strongly advise bumping the protocol minor > >> version number, so that you don't have weird behavior should you try > >> to interoperate with standard code. > >> > >> This is another thing that should be on the list of stuff to fix when > >> we next change the FE/BE protocol ... > > > Comment added to source that SM_USER length should match the others. > > Actually, I had no such change in mind. IMHO the right fix is to > eliminate the fixed-width fields entirely. I see no good reason why > the startup packet shouldn't be several null-terminated strings with > no presupposed lengths. In most cases that would actually make the > packet shorter than it is now. > > We'd probably want an overall sanity-check limit on the packet size, > but it could be of the order of 10K without any problem that I could > see. I added another comment at the top of those defines: /* These should all be of near-unlimited length, perhap 10k */ I left the SM_USER comment in because we should document that the difference between it and SM_* values is arbitrary. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026