Re: Verhindern, dass im Mehrbenutzerbetrieb mit veralteten Daten gearbteitet wird - Mailing list pgsql-general

From Karsten Hilbert
Subject Re: Verhindern, dass im Mehrbenutzerbetrieb mit veralteten Daten gearbteitet wird
Date
Msg-id 20040507023304.F677@hermes.hilbert.loc
Whole thread Raw
In response to Re: Verhindern, dass im Mehrbenutzerbetrieb mit veralteten Daten gearbteitet wird  (darkburgundi@onlinehome.de (Bastian))
List pgsql-general
Bastian

you are misunderstanding the difference between the "row
number" (there is no such thing inherent in relational
databases) and the primary key (or any other explicitely
numbering column).

The "row number" would be moving when deleting some records --
if it existed. It doesn't exist, however, and can only be
generated on the fly sequentially numbering the rows appearing
as query results. Thusly the order of rows is arbitrary and
not related to the "row number".

OTOH, the primary key, of course, doesn't change when you
delete a row. Neither does a "counting" column. Any column can
be *made* to change upon deletion by using triggers but at least
for primary keys that would be a very unclean thing to do
usually.

I think you need to think more carefully about your
application design and not select records for deletion based
on their line number in some frontend view but rather based
on their primary key that is kept with the data making up the
frontend display (it needn't be shown, though).

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

pgsql-general by date:

Previous
From: "Uwe C. Schroeder"
Date:
Subject: Re: Verhindern, dass im Mehrbenutzerbetrieb mit veralteten Daten gearbteitet wird
Next
From: Tom Lane
Date:
Subject: Re: 7.2 or 7.4 for critical data?