Hallo,
in eine Warenwirtschaftsanwendung (lx-office) mit PostgreSQL als
Datenbank gibt es eine Tabelle 'orderitems' mit folgendem Aufbau
Tabelle =C2=BBpublic.orderitems=C2=
=AB
Spalte | Typ |
Attribute =

--------------------+-----------------------------+--------- ---------------=
-------------------------------
trans_id | integer |
parts_id | integer |
description | text |
qty | real |
sellprice | numeric(15,5) |
discount | real |
project_id | integer |
reqdate | date |
ship | real |
serialnumber | text |
id | integer | Vorgabewert
nextval(('orderitemsid'::text)::regclass)
itime | timestamp without time zone | Vorgabewert now()
mtime | timestamp without time zone |
pricegroup_id | integer |
ordnumber | text |
transdate | text |
cusordnumber | text |
unit | character varying(20) |
base_qty | real |
subtotal | boolean | Vorgabewert false
longdescription | text |
marge_total | numeric(15,5) |
marge_percent | numeric(15,5) |
lastcost | numeric(15,5) |
price_factor_id | integer |
price_factor | numeric(15,5) | Vorgabewert 1
marge_price_factor | numeric(15,5) | Vorgabewert 1
Indexe:
"orderitems_id_key" btree (id)
"orderitems_trans_id_key" btree (trans_id)
Fremdschl=C3=BCssel-Constraints:
"$1" FOREIGN KEY (parts_id) REFERENCES parts(id)

Bei einer anstehenden Programmaktualisierung soll diese u.a. Tabelle
indexiert werden.
Die dazugeh=C3=B6rige SQL-Anweisung meldet Fehler, mit dem Hinweis, das
Datens=C3=A4tze doppelt in dieser Tabelle vorhanden sind.
Meine h=C3=A4ndische =C3=9Cberpr=C3=BCfung zeigte mir, das Datens=C3=A4tze =
mehrfach, also 2,
3 bis 6 fach auftreten.
Diese sind in allen Spalten genau gleich, als auch in 'itime' und
'mtime'.
Wie diese entstanden sind ist derzeit nicht nachvollziehbar.

Frage:
Mit welcher Anweisung kann man diese Tabelle bereinigen, so dass jeder
Datensatz nur einmal auftaucht?

Ich bitte um eure Unterst=C3=BCtzung.

Gru=C3=9F


--
Armin Barth <armin.barth [at] pumpen-barth.de>


--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Armin Barth <armin.barth [at] pumpen-barth.de> wrote:

> Hallo,
> in eine Warenwirtschaftsanwendung (lx-office) mit PostgreSQL als
> Datenbank gibt es eine Tabelle 'orderitems' mit folgendem Aufbau
> Tabelle =BBpublic.orderitems=AB
> Spalte | Typ |
> Attribute
> --------------------+-----------------------------+--------- -----------=
-----------------------------------
> trans_id | integer |
> parts_id | integer |
> description | text |
> qty | real |
> sellprice | numeric(15,5) |
> discount | real |
> project_id | integer |
> reqdate | date |
> ship | real |
> serialnumber | text |
> id | integer | Vorgabewert
> nextval(('orderitemsid'::text)::regclass)
> itime | timestamp without time zone | Vorgabewert now()
> mtime | timestamp without time zone |
> pricegroup_id | integer |
> ordnumber | text |
> transdate | text |
> cusordnumber | text |
> unit | character varying(20) |
> base_qty | real |
> subtotal | boolean | Vorgabewert false
> longdescription | text |
> marge_total | numeric(15,5) |
> marge_percent | numeric(15,5) |
> lastcost | numeric(15,5) |
> price_factor_id | integer |
> price_factor | numeric(15,5) | Vorgabewert 1
> marge_price_factor | numeric(15,5) | Vorgabewert 1
> Indexe:
> "orderitems_id_key" btree (id)
> "orderitems_trans_id_key" btree (trans_id)
> Fremdschlüssel-Constraints:
> "$1" FOREIGN KEY (parts_id) REFERENCES parts(id)
>
> Bei einer anstehenden Programmaktualisierung soll diese u.a. Tabelle
> indexiert werden.
> Die dazugehörige SQL-Anweisung meldet Fehler, mit dem Hinweis, das
> Datensätze doppelt in dieser Tabelle vorhanden sind.
> Meine händische =DCberprüfung zeigte mir, das Datensätze mehrfach=
, also 2,
> 3 bis 6 fach auftreten.
> Diese sind in allen Spalten genau gleich, als auch in 'itime' und
> 'mtime'.
> Wie diese entstanden sind ist derzeit nicht nachvollziehbar.
>
> Frage:
> Mit welcher Anweisung kann man diese Tabelle bereinigen, so dass jeder
> Datensatz nur einmal auftaucht?
>
> Ich bitte um eure Unterstützung.

Als erstes solltest Du die Macher der Software kräftig treten.

Zu Deiner Frage:

test=3D# select * from bla;
a | b | c
---+---+---
1 | 1 | 1
1 | 2 | 3
1 | 2 | 2
1 | 3 | 4
1 | 2 | 3
1 | 1 | 1
(6 Zeilen)

Zeit: 0,165 ms
test=3D*# select distinct on (a,b,c) ctid, a,b,c from bla;
ctid | a | b | c
-------+---+---+---
(0,1) | 1 | 1 | 1
(0,3) | 1 | 2 | 2
(0,2) | 1 | 2 | 3
(0,4) | 1 | 3 | 4
(4 Zeilen)

Zeit: 0,286 ms
test=3D*# delete from bla where (ctid, a,b,c) not in (select distinct on
(a,b,c) ctid, a,b,c from bla);
DELETE 2
Zeit: 33,910 ms
test=3D*# select * from bla;
a | b | c
---+---+---
1 | 1 | 1
1 | 2 | 3
1 | 2 | 2
1 | 3 | 4
(4 Zeilen)

Zeit: 0,220 ms



Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082=B0, E 13.56889=
=B0

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Hallo Andreas,
danke f=C3=BCr deine schnelle Antwort.

>
> Als erstes solltest Du die Macher der Software kr=C3=A4ftig treten.
>
Habe ich schon versucht, aber die sch=C3=BCtteln sich nur und behaupten es
w=C3=A4re ein Anwenderfehler.
Wie auch immer.
Die L=C3=B6sung ist wichtig.
Also mit der Test-Tabelle habe ich es gerade versucht - klapp wunder
bar.
Nochmals DANKE !

> Zu Deiner Frage:
>
> test=3D# select * from bla;
> a | b | c
> ---+---+---
> 1 | 1 | 1
> 1 | 2 | 3
> 1 | 2 | 2
> 1 | 3 | 4
> 1 | 2 | 3
> 1 | 1 | 1
> (6 Zeilen)
>
> Zeit: 0,165 ms
> test=3D*# select distinct on (a,b,c) ctid, a,b,c from bla;
> ctid | a | b | c
> -------+---+---+---
> (0,1) | 1 | 1 | 1
> (0,3) | 1 | 2 | 2
> (0,2) | 1 | 2 | 3
> (0,4) | 1 | 3 | 4
> (4 Zeilen)
>

Das mit dem 'ctid' ist mir neu
Was ist das -- finde ich in meinem Postgresql-Buch nicht.
Ist das nur eine tempor=C3=A4rer Index?
Denn bei 'SELECT * FROM bla;' taucht er nicht auf.



> Zeit: 0,286 ms
> test=3D*# delete from bla where (ctid, a,b,c) not in (select distinct on
> (a,b,c) ctid, a,b,c from bla);
> DELETE 2
> Zeit: 33,910 ms
> test=3D*# select * from bla;
> a | b | c
> ---+---+---
> 1 | 1 | 1
> 1 | 2 | 3
> 1 | 2 | 2
> 1 | 3 | 4
> (4 Zeilen)
>
> Zeit: 0,220 ms
>
>
>
> Andreas
> --
> Really, I'm not out to destroy Microsoft. That will just be a completely
> unintentional side effect. (Linus Torvalds)
> "If I was god, I would recompile penguin with --enable-fly." (unknown)
> Kaufbach, Saxony, Germany, Europe. N 51.05082=C2=B0, E 13.56=
889=C2=B0
>


Ich melde mich noch mal, wenn ich es mit der Originaltabelle versucht
habe.
Gru=C3=9F
Armin
--
Armin Barth <armin.barth [at] pumpen-barth.de>


--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

aHR0cDovL3d3dy5wb3N0Z3Jlc3FsLm9yZy9kb2NzLzguNC9zdGF0aWMvZGRs
LXN5c3RlbS1jb2x1bW5zLmh0bWwNCg0KR3J1c3MNCg0KLS0tLS1VcnNwcsO8
bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KVm9uOiBwZ3NxbC1kZS1hbGxnZW1l
aW4tb3duZXJAcG9zdGdyZXNxbC5vcmcgW21haWx0bzpwZ3NxbC1kZS1hbGxn
ZW1laW4tb3duZXJAcG9zdGdyZXNxbC5vcmddIEltIEF1ZnRyYWcgdm9uIEFy
bWluIEJhcnRoDQpHZXNlbmRldDogTWl0dHdvY2gsIDI2LiBKYW51YXIgMjAx
MSAwNzozMw0KQW46IEFuZHJlYXMgS3JldHNjaG1lcg0KQ2M6IHBnc3FsLWRl
LWFsbGdlbWVpbkBwb3N0Z3Jlc3FsLm9yZw0KQmV0cmVmZjogUmU6IFtwZ3Nx
bC1kZS1hbGxnZW1laW5dIE1laHJmYWNoZWludHLDpGdlIGluIFRhYmVsbGUg
S29ycmlnaWVyZW4NCg0KSGFsbG8gQW5kcmVhcywNCmRhbmtlIGbDvHIgZGVp
bmUgc2NobmVsbGUgQW50d29ydC4NCg0KPiANCj4gQWxzIGVyc3RlcyBzb2xs
dGVzdCBEdSBkaWUgTWFjaGVyIGRlciBTb2Z0d2FyZSBrcsOkZnRpZyB0cmV0
ZW4uDQo+IA0KSGFiZSBpY2ggc2Nob24gdmVyc3VjaHQsIGFiZXIgZGllIHNj
aMO8dHRlbG4gc2ljaCBudXIgdW5kIGJlaGF1cHRlbiBlcw0Kd8OkcmUgZWlu
IEFud2VuZGVyZmVobGVyLg0KV2llIGF1Y2ggaW1tZXIuDQpEaWUgTMO2c3Vu
ZyBpc3Qgd2ljaHRpZy4NCkFsc28gbWl0IGRlciBUZXN0LVRhYmVsbGUgaGFi
ZSBpY2ggZXMgZ2VyYWRlIHZlcnN1Y2h0IC0ga2xhcHAgd3VuZGVyDQpiYXIu
DQpOb2NobWFscyBEQU5LRSAhDQoNCj4gWnUgRGVpbmVyIEZyYWdlOg0KPiAN
Cj4gdGVzdD0jIHNlbGVjdCAqIGZyb20gYmxhOw0KPiAgYSB8IGIgfCBjDQo+
IC0tLSstLS0rLS0tDQo+ICAxIHwgMSB8IDENCj4gIDEgfCAyIHwgMw0KPiAg
MSB8IDIgfCAyDQo+ICAxIHwgMyB8IDQNCj4gIDEgfCAyIHwgMw0KPiAgMSB8
IDEgfCAxDQo+ICg2IFplaWxlbikNCj4gDQo+IFplaXQ6IDAsMTY1IG1zDQo+
IHRlc3Q9KiMgc2VsZWN0IGRpc3RpbmN0IG9uIChhLGIsYykgY3RpZCwgYSxi
LGMgZnJvbSBibGE7DQo+ICBjdGlkICB8IGEgfCBiIHwgYw0KPiAtLS0tLS0t
Ky0tLSstLS0rLS0tDQo+ICAoMCwxKSB8IDEgfCAxIHwgMQ0KPiAgKDAsMykg
fCAxIHwgMiB8IDINCj4gICgwLDIpIHwgMSB8IDIgfCAzDQo+ICAoMCw0KSB8
IDEgfCAzIHwgNA0KPiAoNCBaZWlsZW4pDQo+IA0KDQpEYXMgbWl0IGRlbSAn
Y3RpZCcgaXN0IG1pciBuZXUgDQpXYXMgaXN0IGRhcyAtLSBmaW5kZSBpY2gg
aW4gbWVpbmVtIFBvc3RncmVzcWwtQnVjaCBuaWNodC4NCklzdCBkYXMgbnVy
IGVpbmUgdGVtcG9yw6RyZXIgSW5kZXg/DQpEZW5uIGJlaSAnU0VMRUNUICog
RlJPTSBibGE7JyB0YXVjaHQgZXIgbmljaHQgYXVmLg0KDQoNCg0KPiBaZWl0
OiAwLDI4NiBtcw0KPiB0ZXN0PSojIGRlbGV0ZSBmcm9tIGJsYSB3aGVyZSAo
Y3RpZCwgYSxiLGMpIG5vdCBpbiAoc2VsZWN0IGRpc3RpbmN0IG9uDQo+IChh
LGIsYykgY3RpZCwgYSxiLGMgZnJvbSBibGEpOw0KPiBERUxFVEUgMg0KPiBa
ZWl0OiAzMyw5MTAgbXMNCj4gdGVzdD0qIyBzZWxlY3QgKiBmcm9tIGJsYTsN
Cj4gIGEgfCBiIHwgYw0KPiAtLS0rLS0tKy0tLQ0KPiAgMSB8IDEgfCAxDQo+
ICAxIHwgMiB8IDMNCj4gIDEgfCAyIHwgMg0KPiAgMSB8IDMgfCA0DQo+ICg0
IFplaWxlbikNCj4gDQo+IFplaXQ6IDAsMjIwIG1zDQo+IA0KPiANCj4gDQo+
IEFuZHJlYXMNCj4gLS0gDQo+IFJlYWxseSwgSSdtIG5vdCBvdXQgdG8gZGVz
dHJveSBNaWNyb3NvZnQuIFRoYXQgd2lsbCBqdXN0IGJlIGEgY29tcGxldGVs
eQ0KPiB1bmludGVudGlvbmFsIHNpZGUgZWZmZWN0LiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIChMaW51cyBUb3J2YWxkcykNCj4gIklmIEkgd2Fz
IGdvZCwgSSB3b3VsZCByZWNvbXBpbGUgcGVuZ3VpbiB3aXRoIC0tZW5hYmxl
LWZseS4iICAgKHVua25vd24pDQo+IEthdWZiYWNoLCBTYXhvbnksIEdlcm1h
bnksIEV1cm9wZS4gICAgICAgICAgICAgIE4gNTEuMDUwODLCsCwgRSAxMy41
Njg4OcKwDQo+IA0KDQoNCkljaCBtZWxkZSBtaWNoIG5vY2ggbWFsLCB3ZW5u
IGljaCBlcyBtaXQgZGVyIE9yaWdpbmFsdGFiZWxsZSB2ZXJzdWNodA0KaGFi
ZS4NCkdydcOfDQpBcm1pbg0KLS0gDQpBcm1pbiBCYXJ0aCA8YXJtaW4uYmFy
dGhAcHVtcGVuLWJhcnRoLmRlPg0KDQoNCi0tIA0KU2VudCB2aWEgcGdzcWwt
ZGUtYWxsZ2VtZWluIG1haWxpbmcgbGlzdCAocGdzcWwtZGUtYWxsZ2VtZWlu
QHBvc3RncmVzcWwub3JnKQ0KVG8gbWFrZSBjaGFuZ2VzIHRvIHlvdXIgc3Vi
c2NyaXB0aW9uOg0KaHR0cDovL3d3dy5wb3N0Z3Jlc3FsLm9yZy9tYWlscHJl
Zi9wZ3NxbC1kZS1hbGxnZW1laW4NCgotLSAKU2VudCB2aWEgcGdzcWwtZGUt
YWxsZ2VtZWluIG1haWxpbmcgbGlzdCAocGdzcWwtZGUtYWxsZ2VtZWluQHBv
c3RncmVzcWwub3JnKQpUbyBtYWtlIGNoYW5nZXMgdG8geW91ciBzdWJzY3Jp
cHRpb246Cmh0dHA6Ly93d3cucG9zdGdyZXNxbC5vcmcvbWFpbHByZWYvcGdz
cWwtZGUtYWxsZ2VtZWluCg==

--0016e65b64f21aa5d8049abbe344
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hallo Armin!

>
> > Als erstes solltest Du die Macher der Software kr=C3=A4ftig treten.
> >
> Habe ich schon versucht, aber die sch=C3=BCtteln sich nur und behaupten e=
s w=C3=A4re
> ein Anwenderfehler.
> Wie auch immer.
> Die L=C3=B6sung ist wichtig.


ich bezweifle, da=C3=9F Treten hilft :) Du hast recht, die L=C3=B6sung ist =
JETZT
wichtig.

Mittelfristig KANN dies kein Anwenderfehler alleine sein: d.h., vermutlich
hat der Softwaremacher recht, da=C3=9F hier die Anwender b=C3=B6ses eingetr=
agen haben.

ABER die Datenbanktechnik ernstzunehmender Datenbanken kann das seit mehr
als einem Jahrzehnt zuverl=C3=A4ssig verhindern:
=C3=BCber die entsprechenden Spalten ein UNIQUE-Constraint legen. Wenn dann
irgendwer doppelte Eintr=C3=A4ge reinmachen will (Anwender, Software), wird=
das
verhindert. Einzige Probleme sind dann noch kosmische Strahlen und
wear-and-tear der Datentr=C3=A4ger.
Da Du ja ADMIN-Zugriff auf die DB hast, solltest Du (nach REparatur) ein
solches Constraint einrichten:

http://www.postgresql.org/docs/8.4/static/ddl-constraints.ht ml
5.3.3. Unique Constraints
(geht nat=C3=BCrlich auch mit Alter Table)

Gru=C3=9F

Harald



> --

Harald Armin Massa www.2ndQuadrant.com
PostgreSQL Training, Services and Support

2ndQuadrant Deutschland GmbH
GF: Harald Armin Massa

--0016e65b64f21aa5d8049abbe344
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hallo Armin!<div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"=
><div class=3D"im"><br>
> Als erstes solltest Du die Macher der Software kr=C3=A4ftig treten.<br=
>
><br>
</div>Habe ich schon versucht, aber die sch=C3=BCtteln sich nur und behaupt=
en es=C2=A0w=C3=A4re ein Anwenderfehler.<br>
Wie auch immer.<br>
Die L=C3=B6sung ist wichtig.</blockquote><div><br></div><div>ich bezweifle,=
da=C3=9F Treten hilft :) Du hast recht, die L=C3=B6sung ist JETZT wichtig.=
</div><div><br></div><div>Mittelfristig KANN dies kein Anwenderfehler allei=
ne sein: d.h., vermutlich hat der Softwaremacher recht, da=C3=9F hier die A=
nwender b=C3=B6ses eingetragen haben.</div>
<div><br></div><div>ABER die Datenbanktechnik ernstzunehmender Datenbanken =
kann das seit mehr als einem Jahrzehnt zuverl=C3=A4ssig verhindern:</div><d=
iv>=C3=BCber die entsprechenden Spalten ein UNIQUE-Constraint legen. Wenn d=
ann irgendwer doppelte Eintr=C3=A4ge reinmachen will (Anwender, Software), =
wird das verhindert. Einzige Probleme sind dann noch kosmische Strahlen und=
wear-and-tear der Datentr=C3=A4ger.</div>
<div>Da Du ja ADMIN-Zugriff auf die DB hast, solltest Du (nach REparatur) e=
in solches Constraint einrichten:</div><div><br></div><div><a href=3D"http:=
//www.postgresql.org/docs/8.4/static/ddl-constraints.html">h ttp://www.postg=
resql.org/docs/8.4/static/ddl-constraints.html</a></div>
<div><span class=3D"Apple-style-span" style=3D"font-family: verdana, sans-s=
erif; font-size: 12px; "><h2 class=3D"SECT2" style=3D"font-size: 1.2em !imp=
ortant; margin-top: 2ex; margin-right: 0em; margin-bottom: 1.2em; margin-le=
ft: 0em; font-weight: bold; color: rgb(102, 102, 102); ">
<a name=3D"AEN2316">5.3.3. Unique Constraints</a></h2><div><a name=3D"AEN23=
16">(geht nat=C3=BCrlich auch mit Alter Table)</a></div></span></div><div><=
br></div><div>Gru=C3=9F</div><div><br></div><div>Harald</div><div><br></div=
><div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">--=C2=A0</blockquote></div>Harald Armin Mas=
sa =C2=A0 =C2=A0=C2=A0<a href=3D"http://www.2ndQuadrant.com" target=3D"_bla=
nk">www.2ndQuadrant.com</a><div>
PostgreSQL =C2=A0Training, Services =C2=A0and Support</div><div><br></div><=
div>2ndQuadrant Deutschland GmbH=C2=A0</div><div><div>GF: Harald Armin Mass=
a</div></div><br>
</div>

--0016e65b64f21aa5d8049abbe344--

Hallo Andreas,
es hat auch mit der Originaltabelle funktioniert.
(mit Sicherheitskopie vorher)
669 Datens=C3=A4tze sind auf 219 zusammengeschmolzen.

Leider mag die Umstellungs-SQL-Anweisung von Lx-Office
mein Tabelle immer noch nicht, da angeblich immer noch
doppelte Werte vorhanden sind.
Ich suche weiter und werde mal die SQL-Anweisung inspizieren,
wo nach diese die Unterscheidungsmerkmale trifft.

Sicher w=C3=A4re ein PK hier sinnvoller gewesen.
Das soll ja nun offensichtlich beim Update nachgeholt werden.

Offen sichtlich sind es folgende Datens=C3=A4tze, die sich jedoch in der
Spalte 'description' und 'price' unterscheiden.

ctid | trans_id | parts_id | id | itime |
mtime
--------+----------+----------+-----+----------------------- -----+---------=
-------------------
(1,29) | 3322 | 3311 | 10 | 2008-01-07 10:42:24.546097 |
2008-08-13 08:05:26.049818
(5,12) | 3322 | 3311 | 10 | 2008-01-07 10:42:24.546097 |
2008-08-20 06:57:03.763137
(1,30) | 3322 | 3316 | 11 | 2008-01-07 10:42:24.546097 |
2008-08-13 08:05:26.049818
(0,11) | 3322 | 3316 | 11 | 2008-01-07 10:42:24.546097 |
2008-08-20 06:57:03.763137
(1,31) | 3322 | 3318 | 12 | 2008-01-07 10:42:24.546097 |
2008-08-13 08:05:26.049818
(2,24) | 3322 | 3318 | 12 | 2008-01-07 10:42:24.546097 |
2008-08-20 06:57:03.763137


Hier wird mit als Anwender wohl nichts anders =C3=BCbrig bleiben, als mich =
zu
entscheiden, welchen der beiden Dubletten ich weiter verwenden will.

Oder?


> >
> >>
> >> Als erstes solltest Du die Macher der Software kr=C3=A4ftig treten.
> >>
> > Habe ich schon versucht, aber die sch=C3=BCtteln sich nur und behaupten=
es
> > w=C3=A4re ein Anwenderfehler.
> > Wie auch immer.
>
> Es ist ein Designfehler, wenn da kein PK ist und daher Dubletten auftauch=
en.
>
> > Die L=C3=B6sung ist wichtig.
>
> ACK.
> >
> > Das mit dem 'ctid' ist mir neu
> > Was ist das -- finde ich in meinem Postgresql-Buch nicht.
> > Ist das nur eine tempor=C3=A4rer Index?
>
> Warum schaust nicht mal in die offizielle Online-Doku und nutzt deren
> Suchfunktion?
>
> the current tuple ID (CTID). This is a system column containing the file
> block number and position in the block for the row.
>
Danke f=C3=BCr den Hinweis. Mit den System Columns hatte ich bisher nichts =
zu
tun. Nun wei=C3=9F ich mehr.
>
>
> > Denn bei 'SELECT * FROM bla;' taucht er nicht auf.
>
> Ja, wenn Du nicht ctid,* abfragst, bekommst die Spalte auch nicht zu
> sehen. Sie ist aber in jeder Tabelle vorhanden, und noch weitere. Die
> Doku kennt sie alle ...
>
> >
> > Ich melde mich noch mal, wenn ich es mit der Originaltabelle versucht
> > habe.
>
> Ich werf da mal noch ein Reizwort in den Raum: Backup.
>
s.o. -- habe ich ber=C3=BCcksichtig
>
> Btw.: wir hosten hier auch PostgreSQL ;-)
>


--
Armin Barth <armin.barth [at] pumpen-barth.de>


--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein