Bug report #5608
Value in Primary Key Field with Sequence Is Ignored When New Feature Is Added
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | Data Provider/PostGIS | ||
| Affected QGIS version: | master | Regression?: | No |
| Operating System: | Ubuntu | Easy fix?: | No |
| Pull Request or Patch supplied: | No | Resolution: | fixed |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 15181 |
Description
See thread [Qgis-user] QGis 1.7.4 possible bug with PostgreSQL/Postgis manual integer primary key? http://lists.osgeo.org/pipermail/qgis-user/2012-May/017113.html.
Steps to reproduce:
1) Add PostGIS layer.
2) Toggle Editing
3) Add Feature (e.g. with Capture Polygon tool)
4) Dialog box with available attribute fields appears when shape is created
5) Note that primary key defined with sequence appears with default value nextval('sequence_name'::regclass)
6) Alter default value of primary key to some specific desired value
7) Turn off editing/save changes
8) Open attribute table
9) Note that value is next one supplied by PostGIS sequence, NOT value supplied by user.
nextval() from sequence is a default value. Supplying a specific value via a manual INSERT statement or using pgAdmin edit grid respects user input. Therefore it appears that QGIS is programmed to ignore user-supplied value, resulting in default value supplied by sequence. This is inconsistent with other QGIS behavior in that QGIS allows user to edit existing primary key values and change them to any value which does not result in a key violation.
Desired behavior should be discussed. It seems the choices are (a) respect user input, or (b) do not allow user input.
Using QGIS 1.7.4 on Ubuntu 10.04, running against PostGIS 1.4/PostgreSQL 8.4.
History
#1
Updated by Jürgen Fischer over 12 years ago
Not reproducable with master.
Creating a table with:
DROP TABLE IF EXISTS bar;
CREATE TABLE bar(
id SERIAL PRIMARY KEY,
name varchar
);
SELECT AddGeometryColumn('bar','geom',4326,'POLYGON',2);
and creating 4 features in a row and then committing produces
id | name
------+------------------------------------
1 | leaving default for the first
2 | leaving default for the second too
1000 | setting 1000 for the third
3 | and setting 3 for the fourth
Which looks just like I would expect.
#2
Updated by Lee Hachadoorian over 12 years ago
Tested with master. Can confirm correct behavior, so this is an old/already fixed problem. Affected version should have been set to 1.7.4 when I created the issue.
#3
Updated by Jürgen Fischer over 12 years ago
- Resolution set to fixed
- Status changed from Open to Closed
Lee Hachadoorian wrote:
Tested with master. Can confirm correct behavior, so this is an old/already fixed problem. Affected version should have been set to 1.7.4 when I created the issue.
Ok. Closing in that case.