#27452: Add Postgres serial field to contrib.postgres
----------------------------------+--------------------------------------
     Reporter:  Johannes Hoppe    |                    Owner:  (none)
         Type:  New feature       |                   Status:  new
    Component:  contrib.postgres  |                  Version:  1.10
     Severity:  Normal            |               Resolution:
     Keywords:                    |             Triage Stage:  Unreviewed
    Has patch:  0                 |      Needs documentation:  0
  Needs tests:  0                 |  Patch needs improvement:  0
Easy pickings:  0                 |                    UI/UX:  0
----------------------------------+--------------------------------------
Description changed by Burhan Khalid:

Old description:

> Since we have the beautiful `contrib.postgres` package now, we can add a
> couple more Postgres specific fields, that are not supported by MySQL but
> handy to all the Postgres fan boys.
>
> That being said, I guess it's a good idea to start with a serial field. A
> serial is a 4 byte integer with an implicit sequence. Ergo its and auto
> increment field for none primary keys! Yeah!
>
> **Usecase:** You could have a customer number, or invoice number in your
> code. Usually it is a good idea to not use a natural primary key,
> therefore reusing the pk as that number could be considered bad. Having a
> separate field with a separate sequence solves this issue.

New description:

 Since we have the beautiful `contrib.postgres` package now, we can add a
 couple more Postgres specific fields, that are not supported by MySQL but
 handy to all the Postgres fan boys.

 That being said, I guess it's a good idea to start with `Serial`.

 The PostgreSQL documentation: https://www.postgresql.org/docs/9.1/static
 /datatype-numeric.html describes the field as follows:

  The data types `serial` and `bigserial` are not true types, but merely a
 notational convenience for creating unique identifier columns (similar to
 the AUTO_INCREMENT property supported by some other databases).

 **Use Cases:**

 1. Anywhere an automatic incrementing value is required, but a primary key
 is often (mis)used.
 2. Providing additional (user controlled) auto-incrementing values.


 The primary benefit is that is isolates the primary key for the sole use
 of maintaining referential integrity.

--

--
Ticket URL: <https://code.djangoproject.com/ticket/27452#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.ab04e9b9b72adcd3d1b7cbf236e630d7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to