Hello,
Le samedi 28 février 2015, 04:43:53 Régis Haubourg a écrit :
Hi,
well pgadmin sets table view in readonly mode if no Primary Key is defined..
That is more than a good practice from a DBA point of view, I wouldn't be
against such a constraint for tables. We should raise some user
Hi,
well pgadmin sets table view in readonly mode if no Primary Key is defined..
That is more than a good practice from a DBA point of view, I wouldn't be
against such a constraint for tables. We should raise some user warning when
connecting to PG, so that users don't get confuzed
Another
On Fri, Feb 27, 2015 at 04:57:39PM +0100, Jürgen E. Fischer wrote:
Hi Sandro,
On Fri, 27. Feb 2015 at 16:43:23 +0100, Sandro Santilli wrote:
Victor, I've been thinking of this problem overnight and thought
that maybe it could be fixed by having QGIS use UPDATE..RETURNING
to update the
On Fri, Feb 06, 2015 at 12:54:20PM +0100, Victor Olaya wrote:
Correct, no PK in my table. What you say sounds feasible. I will try
with another table that has a PK, and see if I can reproduce the error
or not.
I cannot expect to have a PK in the user's table, but this is at least
a clue :-)
Hi Sandro,
On Fri, 27. Feb 2015 at 16:43:23 +0100, Sandro Santilli wrote:
Victor, I've been thinking of this problem overnight and thought
that maybe it could be fixed by having QGIS use UPDATE..RETURNING
to update the associated key.
And return it where? In the current vector provider
Hi Sandro,
On Fri, 27. Feb 2015 at 17:35:37 +0100, Sandro Santilli wrote:
In any case the reported behavior does sound like a bug to me, so
I still think it should get a ticket, don't you ?
Well, ctid is not a reliable key. The ctid will also change if something else
modifies the row.
On Fri, Feb 27, 2015 at 08:37:11PM +0100, Jürgen E. Fischer wrote:
Hi Sandro,
On Fri, 27. Feb 2015 at 17:35:37 +0100, Sandro Santilli wrote:
In any case the reported behavior does sound like a bug to me, so
I still think it should get a ticket, don't you ?
Well, ctid is not a reliable
Correct, no PK in my table. What you say sounds feasible. I will try
with another table that has a PK, and see if I can reproduce the error
or not.
I cannot expect to have a PK in the user's table, but this is at least
a clue :-)
Thanks!
2015-02-06 12:48 GMT+01:00 Martin Dobias
Hi all,
I am seeing a behaviour that surprised me when editing a PostGIS
layer. HEre's a detailed explanation
Let's say I have a layer with 3 features with ids 1,2 and 3. In a
layer such as a shapefile, if you move the feature with the id 1, the
geometryChanged signal is fired, with the feature
Hi Victor
On Fri, Feb 6, 2015 at 5:39 PM, Victor Olaya vola...@gmail.com wrote:
In the case of a PostGIS layer, when the editingStopped signal is
emitted, the query will return no features. The feature with id 1 is
no longer there, and instead there will be a feature with id equal to
4. So
10 matches
Mail list logo
