QGIS » QGIS Application

it happens only when in the dialog the user does not specify the primary key by enabling the "primary key" checkbox, so while it a very boring bug for real work, it is not that critical.

Why not setting the box checked by default?

A more specific explanation of the problem:

A "serial" data type in PostgreSQL is syntactic sugar for "integer NOT NULL DEFAULT nextval('some_sequence'::regclass)", combined with the implicit creation of the sequence used in the DEFAULT clause.

So the D&D function do create the correct base type for the column, but fails to create the corresponding sequence and the default clause for the column.

See also #14104

This issue is quite annoying and it's unfixed for 3 years. Can someone set the priority to high or blocker?

Paul Kanelli wrote:

This issue is quite annoying and it's unfixed for 3 years. Can someone set the priority to high or blocker?

we usually don't raise priority based on age of tickets. Blockers are regressions, and high priority is usually reserved for issues causing crash or data corruption (that are not regressions). This issue does not fit either.

Thx for the info. Here comes the workaround:

SELECT S E T V A L('<schema><table>_<column>_seq', (SELECT M A X(<column>) FROM <schema>.<table>));

ALTER TABLE <schema>.<table>
ALTER COLUMN <column> SET DEFAULT nextval('<schema><table>_<column>_seq'::regclass);

Please ignore the spaces in SETVAL and MAX.

Example:

SELECT S E T V A L('public.buildings_gid_seq', (SELECT M A X(gid) FROM public.buildings));

ALTER TABLE public.buildings
ALTER COLUMN gid SET DEFAULT nextval('public.buildings_gid_seq'::regclass);

Paul - Thanks for the work around. I'll have to test that.
This is definitely an annoying bug. I only found this out recently when we decided to switch to PostGIS/QGIS as our main production workflow. Anytime you need to move a table from one location to another, you have to create a new primary key column (check primary key box and type in a new column name) otherwise you are unable to add any new records to those imported tables.

I would love to see this one fixed!

Paul Kanelli wrote:

Thx for the info. Here comes the workaround:

SELECT S E T V A L('<table>_<column>_seq', (SELECT M A X(<column>) FROM <schema>.<table>));

ALTER TABLE <schema>.<table>
ALTER COLUMN <column> SET DEFAULT nextval('<table>_<column>_seq'::regclass);

Please ignore the spaces in SETVAL and MAX.

if this is a patch that can be applied in DB manager code please submit it via pull request in the QGIS github repository.

Hi Giovanni, it's just a SQL query to sync the primary key. I've no programming skills.

Related: #14712

Is there any chance that we get this issue fixed soon?

(In some cases the name of the primary key is placed in quotes when copying a table by D&D (see also: #15226). After removing the quotes in the "Import vector layer" dialog, adding new features works properly. To me, this is really mysterious.)

EDIT: fixed

In QGIS 2.18.0 the sequence is completely missing after copying a table by D&D, but maybe this is better than a broken seuqence.

See also: #15991

Reinhard Reiterer wrote:

Here comes a workaround for the missing sequence ...created with a lot of help from gis.stackexchange.com.

it would be nice of you can do a PR to add this script to

https://github.com/qgis/QGIS-Processing