Value in Primary Key Field with Sequence Is Ignored When New Feature Is Added

[qgib]

Author Name: Lee Hachadoorian (Lee Hachadoorian)
Original Redmine Issue: 5608
Affected QGIS version: master
Redmine category:data_provider/postgis

---

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.

[qgib]

Author Name: Jürgen Fischer (@jef-n)

---

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.

[qgib]

Author Name: Lee Hachadoorian (Lee Hachadoorian)

---

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.

[qgib]

Author Name: Jürgen Fischer (@jef-n)

---

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.

---

• resolution was changed from to fixed
• status_id was changed from Open to Closed