Re: HOWTO - Random character generation for primary key

Поиск
Список
Период
Сортировка
От Joel Burton
Тема Re: HOWTO - Random character generation for primary key
Дата
Msg-id JGEPJNMCKODMDHGOBKDNCEPKCMAA.joel@joelburton.com
обсуждение исходный текст
Ответ на Re: HOWTO - Random character generation for primary key  (Lincoln Yeoh <lyeoh@pop.jaring.my>)
Список pgsql-general
Could you:

. Keep your 10-letter char keys in table

. create a sequence (manually, with CREATE SEQUENCE)

. create the table with a default value of next_charkey()

. next_charkey() calls nextval() to get the next value of the sequence and
converts this to a 10-char symbol (pick your own int -> char conversion
routine) and returns to the table

There will be more overhead, so if you're adding lots of records,
next_charkey() should be done in C.

Joel BURTON | joel@joelburton.com | joelburton.com | aim: wjoelburton
Knowledge Management & Technology Consultant

> -----Original Message-----
> From: pgsql-general-owner@postgresql.org
> [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Lincoln Yeoh
> Sent: Monday, May 06, 2002 9:47 AM
> To: Alan Wayne; jm.poure@freesurf.fr
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] HOWTO - Random character generation for primary
> key
>
>
> What are you trying to achieve? There doesn't seem to be enough
> information
> to help you properly.
>
> a) What do your 10 character keys look like? visible ASCII? legal Base64
> charset?
> b) How were they generated previously?
> c) Why do you think they need to look that way?
> d) Can you really change your app to use ints?
>
> Regards,
> Link.
>
> At 12:09 PM 5/4/02 -0700, Alan Wayne wrote:
> >Hi!
> >So ultimately, the better way would be to
> >bite-the-bullet and work towards replacing the current
> >character keys with int4 keys?
> >
> >(This will be quite time consuming on several million
> >records and about 35 tables with referential integrity
> >rules--a quick and dirty way would be appreciated.)
> >
> >Cheers,
> >Alan
> >
> >--- Jean-Michel POURE <jm.poure@freesurf.fr> wrote:
> > > Dear Alan,
> > >
> > > When you write me, please CC me on
> > > pgsql-general@postgresql.org so that anyone
> > > can participate.
> > >
> > > > Question: What would happen if I did the
> > > following:
> > > >    1. used some variant of "alter table" to change
> > > the
> > > > character field primary key to a field of type
> > > > 'serial'? i.e., would the binary form of the
> > > current
> > > > 10 length characters be preserved as some kind of
> > > > integer?
> > >
> > > In PostgreSQL, serial values are int4 auto-increment
> > > values. Therefore, there
> > > is no easy way to migrate your 10 characters long
> > > primary keys.
> > >
> > > By the way PostgreSQL does not support type
> > > promotion <-> demotion. You will
> > > have to wait for 7.3 or later to convert column
> > > types. For example, you
> > > cannot change an in4 into an int8, a varchar into a
> > > text column.
> > >
> > > Presently the solution is to add an int4 field to
> > > your tables ... and fill
> > > them with incremental values ... and update sequence
> > > values by hand.
> > >
> > > When your done, rename your tables with '_old',
> > > recreate them without 10
> > > characters primary keys and fill them with data.
> > >
> > > This should be easy in pgAdmin2 because you can copy
> > > table definition
> > > and paste it in the execution window. pgAdmin2 also
> > > gives you access to
> > > sequences.
> > >
> > > >   2. If postgresql does allow me to change the
> > > primary
> > > > key field from character to type serial (i.e.,
> > > > integer) in the first table, what will the
> > > referential
> > > > integrity rules do to the other tables that use
> > > the
> > > > first table's primary key as a secondary key?
> > > i.e.,
> > > > does postgre preceive the change of data-type as a
> > > > change to be echoed to the referencing tables via
> > > the
> > > > referential integrity rules? Furthermore, would
> > > this
> > > > recognition only be on newly added records, or on
> > > the
> > > > records already in the tables? e.g., if no change
> > > is
> > > > detected until a new record is added, could I go
> > > > through the database one table at a time and
> > > change
> > > > the referencing fields to type integer to match
> > > the
> > > > change in the primary key? (Needless to say, I
> > > can't
> > > > alter the keys without all the related records
> > > being
> > > > changed too--or I lose my relationships).
> > > > The current records are using pure characters of
> > > 10
> > > > byte length. If postgre could accept the above
> > > changes
> > > > before adding new records, then could the simple
> > > type
> > > > 'serial' be used without having the default
> > > produced
> > > > integers on new records clobber the existing
> > > > 'characters' ?
> > >
> > > If you don't want to migrate, set primary key column
> > > default value to
> > > random_string(10). See my previous HOWTO.
> > >
> > > Please note this is not a very standard way to
> > > proceed. In a profesionnal
> > > environment, you should use integer primary keys.
> > >
> > > Example :
> > > CREATE TABLE foo (
> > > foo_oid serial,
> > > foo_name varchar(254),
> > > foo_text text)
> > > WITH OIDS;
> > >
> > > is better than
> > >
> > > CREATE TABLE bar (
> > > bar_key char(10) random_string(10),
> > > bar_name varchar(254),
> > > bar_text text)
> > > WITH OIDS;
> >
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Yahoo! Health - your guide to health and wellness
> >http://health.yahoo.com
> >
> >---------------------------(end of broadcast)---------------------------
> >TIP 2: you can get off all lists at once with the unregister command
> >     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>


В списке pgsql-general по дате отправления:

Предыдущее
От: "William N. Zanatta"
Дата:
Сообщение: Re: [POSTGRESQL] LOCKING A ROW
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [POSTGRESQL] LOCKING A ROW