Opened 7 years ago

Last modified 4 weeks ago

#27452 assigned New feature

Add Postgres serial field to contrib.postgres

Reported by: Johannes Maron Owned by: InvalidInterrupt
Component: contrib.postgres Version: dev
Severity: Normal Keywords:
Cc: info@…, InvalidInterrupt Triage Stage: Accepted
Has patch: yes Needs documentation: yes
Needs tests: yes Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Burhan Khalid)

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.

Change History (24)

comment:1 by Burhan Khalid, 7 years ago

Description: modified (diff)

comment:2 by Johannes Maron, 7 years ago

I opened a PR with an implementation that I am already using somewhere. It added a couple of tests and documentation too.
I guess this is a good starting point for a discussion.

Last edited 7 years ago by Tim Graham (previous) (diff)

comment:3 by Johannes Maron, 7 years ago

Owner: set to Johannes Maron
Status: newassigned

comment:4 by Tim Graham, 7 years ago

Has patch: set
Patch needs improvement: set
Triage Stage: UnreviewedAccepted

comment:5 by Johannes Maron, 5 years ago

Patch needs improvement: unset

comment:6 by Simon Charette, 5 years ago

Patch needs improvement: set

comment:7 by Johannes Maron, 5 years ago

Patch needs improvement: unset

comment:8 by Nick Pope, 5 years ago

Patch needs improvement: set

comment:9 by Nick Pope, 5 years ago

Version: 1.10master

comment:10 by Johannes Maron, 5 years ago

Patch needs improvement: unset

comment:11 by Mariusz Felisiak, 4 years ago

Needs tests: set
Patch needs improvement: set

comment:12 by InvalidInterrupt, 4 years ago

Cc: InvalidInterrupt added

comment:13 by Johannes Maron, 4 years ago

I closed my PR for now, due to a lack of interest. Since Django does support returning values since v3.0 everyone who needs such a field can build it. Yet, I don't have the time get the feature into Django for now.

in reply to:  13 comment:14 by InvalidInterrupt, 4 years ago

Replying to Johannes Hoppe:

I closed my PR for now, due to a lack of interest. Since Django does support returning values since v3.0 everyone who needs such a field can build it. Yet, I don't have the time get the feature into Django for now.

Do you mind if I continue working on this using your branch? Handling sequence resets after loading fixtures will require changes to the DB backend.

comment:15 by Claude Paroz, 4 years ago

Owner: Johannes Maron removed
Status: assignednew

Latest comment from Johannes is clearly an invitation to help :-)

comment:16 by InvalidInterrupt, 4 years ago

Owner: set to InvalidInterrupt
Status: newassigned

comment:17 by InvalidInterrupt, 4 years ago

Needs tests: unset
Patch needs improvement: unset

comment:18 by Mariusz Felisiak, 3 years ago

Needs tests: set
Patch needs improvement: set

comment:19 by InvalidInterrupt, 3 years ago

Needs tests: unset
Patch needs improvement: unset

comment:20 by Johannes Maron, 3 years ago

Hi, the new default patch depends on https://github.com/django/django/pull/11783. Maybe you would care to review this one, to get things moving along faster? Best Joe

comment:21 by Johannes Maron, 3 years ago

Needs documentation: set
Needs tests: set

comment:22 by Claude Paroz, 20 months ago

Does this still make sense now that Django is using identity columns for *AutoFields?

comment:23 by Simon Charette, 17 months ago

Claude, yes I think that the move to identity columns on Postgres made this feature even more desirable (e.g. #34131).

comment:24 by Simon Charette, 4 weeks ago

FWIW someone was able to implement an IdentityField which is kind of the equivalent of GeneratedField if it supported AS IDENTITY. It's not the equivalent of SerialField though but it demonstrates that all the pieces are there to implement it based on db_returning and pre_save returning a Default expression.

Note: See TracTickets for help on using tickets.
Back to Top