QGIS » QGIS Application

The background shows the input table (see 15226.png).

More D&D issues:

#6798 (when copying a table by d&d from one schema to another the serial property is lost in the pk)
#14712 (DB-Manager DEFAULT value d&d issue)

Reinhard can you help me reproduce the issue ? Where should I drag the table from ? Where should I drag it to ? Which versions did you test ? Can you provide SQL to initialize such example test table ?

Interesting, can you inspect the two tables (the one which works and the one which doesn't) with the "psql" command-line database tool ? Can it be the "gid" field is really encoded differently ? Or, can you reproduce after dumping and reloading that table ? Can you spot any other difference between the two tables ? Does it always happen on that table, no matter the order in which you copy them ?

Views are affected, while real table aren't (or so it looks).
The bug was introduced by the commit fixing #13710 (daa6510970e9afbc4d41d28e0c94b4f238eb372d)

\\cc Jurgen

Jurgen, once again this issue is about properly defining semantic for some fields.
In this case is the "keyColumn()" return from QgsDatasourceUri.
Is that supposed to contain quoted or unquoted names ?

Sandro Santilli wrote:

Jurgen, once again this issue is about properly defining semantic for some fields.
In this case is the "keyColumn()" return from QgsDatasourceUri.
Is that supposed to contain quoted or unquoted names ?

the postgres provider handles quoted and unquoted content from keyColumn() - dbmanager should do too.

On further research, I found that we get quoted identifiers in the url when the primary key type is a FidMap. This happens for multi-column keys or for non-integer keys. In both these cases, even with QGIS 2.14, we get quoted attributes in the QgsDatasourceUri keyColumn() return.

In all these cases, the DBManager drag & drop operation results in a target table having quotes in the key column names.
Even in QGIS 2.14.

I'll see how DBManager should deal with quotes, but given the above I guess the only sane way to deal with quotes would be knowing if the quotes were added or were part of the actual field name, so somehow the "FidMap" nature should be exposed.
or we should always quote the columns ?

BTW, I'm not sure it's DBManager or the provider's "CreateEmptyLayer" being responsible of parsing the URL.
Will keep looking.

I confirm it should be createEmptyTable, within the Postgres provider, to interpret the URI.
Hopefully the semantic of that "key" parameter of the URI will only be needed from within the provider

So with PR https://github.com/qgis/QGIS/pull/3599 I've made PostgreSQL layer importer (createEmptyLayer) support quoted identifiers in Datasource URI -- for backward compatibility with projects created #13710 was fixed (that ticket lacks a target version) -- and I've reverted the commit which did add quoted identifiers in Datasource URI as they do seem redundant and inconsistent (I did test that #13710 isn't back).

In its current state, the code in the PR not only fixes this bug but also adds support for Drag&Dropp'ing tables with multi-column keys (including those with mixed-cased-colum names)

Sandro, it's great to see this bug fixed.

Sandro Santilli wrote:

Views are affected, while real table aren't (or so it looks).

As seen in screencast '15226_screencast.wmv' copying tables by D&D may also fail. Is there anything else to do?

To the best of my knowledge copying tables by D&D also succeeds now. If you can test, the working code is in master_2 branch, since dd85796bae24842da078ad2a3e90f451839db993 - reopen if you still see a problem with Drag&Drop and primary key.