Hallo NG,

um Doppeleinträge in der postgres DB zu vermeiden, habe ich in meinem
create table eingefügt:
CONSTRAINT con1 UNIQUE (lastname,firstname)

Wie kann ich den UNIQUE Befehl schreiben, dass die Datensätze nicht doppe=
lt
sind,
bei denen die Bedingung erfüllt ist, dass der lastname "und" der firstname
identisch sind, also
wenn in einer Zeile Bauer Andreas als last- und firstname steht, dass Bauer
und Andreas als first-
und lastname nicht noch mal in einer Zeile der Tabelle eingetragen wird. Es
kann ja auch eine andere Person
den gleichen lastname, aber einen anderen firstname haben. Da würde der=

CONSTRAINT con1 UNIQUE (lastname,firstname) ja schon den lastname nicht
zulassen,
oder lieg ich da falsch? Geht das überhaupt mit UNIQUE, mit einer &
Verknüpfung von den Feldern?
Die pq-query Fehlermeldung von php:
Warning: pg_query() [function.pg-query]: Query failed: ERROR: duplicate key
violates unique constraint "con1" in
Kann man die abschalten?


Grüße
Andreas




create table t_authors
(
authorid int4 primary key
default nextval('s_authors'),
lastname varchar(31) not null,
firstname varchar(31) not null,
CONSTRAINT con1 UNIQUE (lastname,firstname)

);


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

QmlzdCBEdSBzaWNoZXIsIGRhw58gRHUgZGFzIHdpcmtsaWNoIHdpbGxzdD8g
RsO8ciBtaWNoIGtsaW5ndCBkYXMgbmFjaAplaW5lciB6aWVtbGljaCBzY2hs
ZWNodGVuIElkZWUuIEF1w59lciBuYXTDvHJsaWNoLCBEdSBrYW5uc3QKR0FS
QU5USUVSRU4sIGRhw58gRHUgbmllIGVpbmUgUGVyc29uIGF1Zm5laG1lbiB3
aWxsc3QsIGRpZSBkZW4KQmVkaW5ndW5nZW4gbmljaHQgZ2Vuw7xndC4KCk51
ciBzbyBhdXMgSW50ZXJlc3NlOiB3YXJ1bSBzb2xsIGRhcyBzbyBzZWluPwoK
Y3VnCgpPbiAxMS8xMC8wNiwgQW5kcmVhcyBCYXVlciA8YW5kcmVhc19iYXVl
ckBhcmNvci5kZT4gd3JvdGU6Cj4gSGFsbG8gTkcsCj4KPiB1bSBEb3BwZWxl
aW50csOkZ2UgaW4gZGVyIHBvc3RncmVzIERCIHp1IHZlcm1laWRlbiwgaGFi
ZSBpY2ggaW4gbWVpbmVtCj4gY3JlYXRlIHRhYmxlIGVpbmdlZsO8Z3Q6Cj4g
Q09OU1RSQUlOVCBjb24xIFVOSVFVRSAobGFzdG5hbWUsZmlyc3RuYW1lKQo+
Cj4gV2llIGthbm4gaWNoIGRlbiBVTklRVUUgQmVmZWhsIHNjaHJlaWJlbiwg
ZGFzcyBkaWUgRGF0ZW5zw6R0emUgbmljaHQgZG9wcGVsdAo+IHNpbmQsCj4g
YmVpIGRlbmVuIGRpZSBCZWRpbmd1bmcgZXJmw7xsbHQgaXN0LCBkYXNzIGRl
ciBsYXN0bmFtZSAidW5kIiBkZXIgZmlyc3RuYW1lCj4gaWRlbnRpc2NoIHNp
bmQsIGFsc28KPiB3ZW5uIGluIGVpbmVyIFplaWxlIEJhdWVyIEFuZHJlYXMg
YWxzIGxhc3QtIHVuZCBmaXJzdG5hbWUgc3RlaHQsIGRhc3MgQmF1ZXIKPiB1
bmQgQW5kcmVhcyBhbHMgZmlyc3QtCj4gdW5kIGxhc3RuYW1lIG5pY2h0IG5v
Y2ggbWFsIGluIGVpbmVyIFplaWxlIGRlciBUYWJlbGxlIGVpbmdldHJhZ2Vu
IHdpcmQuICBFcwo+IGthbm4gamEgYXVjaCBlaW5lIGFuZGVyZSBQZXJzb24K
PiBkZW4gZ2xlaWNoZW4gbGFzdG5hbWUsIGFiZXIgZWluZW4gYW5kZXJlbiBm
aXJzdG5hbWUgaGFiZW4uIERhIHfDvHJkZSBkZXIKPiBDT05TVFJBSU5UIGNv
bjEgVU5JUVVFIChsYXN0bmFtZSxmaXJzdG5hbWUpIGphIHNjaG9uIGRlbiBs
YXN0bmFtZSBuaWNodAo+IHp1bGFzc2VuLAo+IG9kZXIgbGllZyBpY2ggZGEg
ZmFsc2NoPyBHZWh0IGRhcyDDvGJlcmhhdXB0IG1pdCBVTklRVUUsIG1pdCBl
aW5lciAmCj4gVmVya27DvHBmdW5nIHZvbiBkZW4gRmVsZGVybj8KPiBEaWUg
cHEtcXVlcnkgRmVobGVybWVsZHVuZyB2b24gcGhwOgo+IFdhcm5pbmc6IHBn
X3F1ZXJ5KCkgW2Z1bmN0aW9uLnBnLXF1ZXJ5XTogUXVlcnkgZmFpbGVkOiBF
UlJPUjogZHVwbGljYXRlIGtleQo+IHZpb2xhdGVzIHVuaXF1ZSBjb25zdHJh
aW50ICJjb24xIiBpbgo+IEthbm4gbWFuIGRpZSBhYnNjaGFsdGVuPwo+Cj4K
PiBHcsO8w59lCj4gQW5kcmVhcwo+Cj4KPgo+Cj4gY3JlYXRlIHRhYmxlIHRf
YXV0aG9ycwo+ICgKPiAgICAgICAgIGF1dGhvcmlkICAgICAgICBpbnQ0ICAg
ICAgICAgICAgcHJpbWFyeSBrZXkKPiAgICAgICAgICAgICAgICAgICAgICAg
ICBkZWZhdWx0IG5leHR2YWwoJ3NfYXV0aG9ycycpLAo+ICAgICAgICAgbGFz
dG5hbWUgICAgICAgICAgICAgICAgdmFyY2hhcigzMSkgICAgIG5vdCBudWxs
LAo+ICAgICAgICAgZmlyc3RuYW1lICAgICAgICAgICAgICAgdmFyY2hhcigz
MSkgICAgIG5vdCBudWxsLAo+ICAgICAgICAgQ09OU1RSQUlOVCBjb24xIFVO
SVFVRSAobGFzdG5hbWUsZmlyc3RuYW1lKQo+Cj4gKTsKPgo+Cj4gLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tKGVuZCBvZiBicm9hZGNhc3QpLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gVElQIDc6IFlvdSBjYW4gaGVscCBz
dXBwb3J0IHRoZSBQb3N0Z3JlU1FMIHByb2plY3QgYnkgZG9uYXRpbmcgYXQK
Pgo+ICAgICAgICAgICAgICAgICBodHRwOi8vd3d3LnBvc3RncmVzcWwub3Jn
L2Fib3V0L2RvbmF0ZQo+CgoKLS0gClBvc3RncmVTUUwgQm9vdGNhbXAsIEJp
ZyBOZXJkIFJhbmNoIEV1cm9wZSwgTm92IDIwMDYKaHR0cDovL3d3dy5iaWdu
ZXJkcmFuY2guY29tL25ld3MvMjAwNi0wOC0yMS5zaHRtbAoKLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tKGVuZCBvZiBicm9hZGNhc3QpLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tClRJUCA3OiBZb3UgY2FuIGhlbHAgc3VwcG9y
dCB0aGUgUG9zdGdyZVNRTCBwcm9qZWN0IGJ5IGRvbmF0aW5nIGF0CgogICAg
ICAgICAgICAgICAgaHR0cDovL3d3dy5wb3N0Z3Jlc3FsLm9yZy9hYm91dC9k
b25hdGUK

>
> Hallo NG,
>
> um Doppeleinträge in der postgres DB zu vermeiden, habe ich
> in meinem create table eingefügt:
> CONSTRAINT con1 UNIQUE (lastname,firstname)
>
> Wie kann ich den UNIQUE Befehl schreiben, dass die Datensätze
> nicht doppelt sind, bei denen die Bedingung erfüllt ist, dass
> der lastname "und" der firstname identisch sind, also wenn in
> einer Zeile Bauer Andreas als last- und firstname steht, dass
> Bauer und Andreas als first- und lastname nicht noch mal in
> einer Zeile der Tabelle eingetragen wird. Es kann ja auch
> eine andere Person den gleichen lastname, aber einen anderen
> firstname haben. Da würde der CONSTRAINT con1 UNIQUE
> (lastname,firstname) ja schon den lastname nicht zulassen,
> oder lieg ich da falsch? Geht das überhaupt mit UNIQUE, mit
> einer & Verknüpfung von den Feldern?
> Die pq-query Fehlermeldung von php:
> Warning: pg_query() [function.pg-query]: Query failed: ERROR:
> duplicate key violates unique constraint "con1" in Kann man
> die abschalten?
>
>
> Grüße
> Andreas
>
nun ich bin mir nicht sicher, aber du wirst wohl um einen trigger
before insert nicht drumherumkommen oder geht=92s doch mit check-constraint?

wer weis es genau?


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo [at] postgresql.org so that your
message can get through to the mailing list cleanly

am Fri, dem 10.11.2006, um 12:53:15 +0100 mailte Andreas Bauer folgendes=
:
> Hallo NG,
>
> um Doppeleinträge in der postgres DB zu vermeiden, habe ich in meinem
> create table eingefügt:
> CONSTRAINT con1 UNIQUE (lastname,firstname)
>
> Wie kann ich den UNIQUE Befehl schreiben, dass die Datensätze nicht d=
oppelt
> sind,
> bei denen die Bedingung erfüllt ist, dass der lastname "und" der firs=
tname
> identisch sind, also
> wenn in einer Zeile Bauer Andreas als last- und firstname steht, dass B=
auer
> und Andreas als first-
> und lastname nicht noch mal in einer Zeile der Tabelle eingetragen wird=
.. Es
> kann ja auch eine andere Person
> den gleichen lastname, aber einen anderen firstname haben. Da würde d=
er

Wir hatten hier bei ca. 100 Mitarbeitern den schönen Fall, gleich 2 mal
gleiche Vor- und Zunamen zu haben. Ist lustig bei der Vergabe von
Mailadressen, da diese hier vorname.zuname [at] domaene.tld lauten...
(va qrz rvara Qbccry zhßgr rvar mjnatfurvengra, vz naqrera jheqr wrzna=
q
ragynffra)


> CONSTRAINT con1 UNIQUE (lastname,firstname) ja schon den lastname nicht
> zulassen,

Mach einen Unique Index auf beide Spalten, das wirkt. Aber ich würde
nicht so sicher sein, daß Vor- und Zuname nicht doppelt vorkommen
können.



> oder lieg ich da falsch? Geht das überhaupt mit UNIQUE, mit einer &
> Verknüpfung von den Feldern?
> Die pq-query Fehlermeldung von php:
> Warning: pg_query() [function.pg-query]: Query failed: ERROR: duplicate=
key
> violates unique constraint "con1" in
> Kann man die abschalten?

Wie jetzt, Du willst einen Constraint, aber nur ein bisschen?


Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47215, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

am Fri, dem 10.11.2006, um 13:00:35 +0100 mailte rene hankel folgendes:
> nun ich bin mir nicht sicher, aber du wirst wohl um einen trigger
> before insert nicht drumherumkommen oder geht=92s doch mit check-constr=
aint?
>
> wer weis es genau?

Warum probierst Du es nicht mal aus?

test=3D# create table doppel (vorname text, zuname text);
CREATE TABLE
test=3D*# create unique index idx_doppel on doppel(vorname,zuname);
CREATE INDEX
test=3D*# insert into doppel values ('andreas', 'kretschmer');
INSERT 0 1
test=3D*# insert into doppel values ('andreas', 'kretschmer');
ERROR: duplicate key violates unique constraint "idx_doppel"


Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47215, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Hallo Guido,
>>Bist Du sicher, daß Du das wirklich willst? Für mich klingt das nach =
einer
ziemlich schlechten Idee. Außer natürlich, Du kannst GARANTIEREN, daß=
Du nie
>>eine Person aufnehmen willst, die den Bedingungen nicht genügt.
>>Nur so aus Interesse: warum soll das so sein?
Na, ich will Doppeleinträge vermeiden. Vielleicht sollte das Feld title d=
er
anderen t_Books Tabelle auch noch in CONSTRAINT UNIQUE
miteinbezogen werden. Das wäre dann schon ein sehr großer Zufall, wenn =
es
tatsächlich 2 identische Autorennamen, Nach- Und Vorname, und noch
2 identische Buchtitel gäbe, wodurch ein Autor dann durch dieses UNIQUE
eleminiert würde.

Die t_books sieht so aus:

create table t_books
(
bookid int4 primary key
default nextval('s_books'),
authorid int4 not null
references t_authors(authorid)
on delete cascade,
=09
FOREIGN KEY (authorid) REFERENCES t_authors (authorid) ON UPDATE
CASCADE ON DELETE CASCADE,
title varchar(127) not null,

subtitle varchar(255)
=09
);


On 11/10/06, Andreas Bauer <andreas_bauer [at] arcor.de> wrote:
> Hallo NG,
>
> um Doppeleinträge in der postgres DB zu vermeiden, habe ich in meinem=

> create table eingefügt:
> CONSTRAINT con1 UNIQUE (lastname,firstname)
>
> Wie kann ich den UNIQUE Befehl schreiben, dass die Datensätze nicht
> doppelt sind, bei denen die Bedingung erfüllt ist, dass der lastname
> "und" der firstname identisch sind, also wenn in einer Zeile Bauer
> Andreas als last- und firstname steht, dass Bauer und Andreas als
> first- und lastname nicht noch mal in einer Zeile der Tabelle
> eingetragen wird. Es kann ja auch eine andere Person den gleichen
> lastname, aber einen anderen firstname haben. Da würde der CONSTRAINT=

> con1 UNIQUE (lastname,firstname) ja schon den lastname nicht zulassen,
> oder lieg ich da falsch? Geht das überhaupt mit UNIQUE, mit einer &
> Verknüpfung von den Feldern?
> Die pq-query Fehlermeldung von php:
> Warning: pg_query() [function.pg-query]: Query failed: ERROR:
> duplicate key violates unique constraint "con1" in Kann man die
> abschalten?
>
>
> Grüße
> Andreas
>
>
>
>
> create table t_authors
> (
> authorid int4 primary key
> default nextval('s_authors'),
> lastname varchar(31) not null,
> firstname varchar(31) not null,
> CONSTRAINT con1 UNIQUE (lastname,firstname)
>
> );

Grüße
Andreas


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

T2theSwgaWNoIHNwaWVsZSBtYWwgImRldmlscyBhZHZvY2F0ZSIgLi4uIHdh
cyBtYWNoc3QgRHUsIHdlbm4gZXMgendlaQp1bnRlcnNjaGllZGxpY2hlIEF1
dG9yZW4gbmFtZW5zICJIYW5zIE3DvGxsZXIiIGdpYnQgbWl0CnVudGVyc2No
aWVkbGljaGVuIFZlcsO2ZmZlbnRsaWNodW5nZW4/IFdhcyBtYWNoc3QgRHUg
YmVpIERlaW5lbSBNb2RlbGwKd2VubiBlaW5lciB2b24gYmVpZGVuIGhlaXJh
dGV0IHVuZCBkYW5uICJIYW5zIE1laWVyIiBoZWnDn3QsIHdlaWwgZXIKZGVu
IE5hbWVuIHNlaW5lciBGcmF1IGFubmltbXQ/IERhcmYgZXIgbmljaHQgaGVp
cmF0ZW4sIHdlaWwgZXMKdmllbGxlaWNodCBzY2hvbiBlaW5lbiBIYW5zIE1l
aWVyIGdpYnQ/CgpOb2NoIGJlc3Nlcjogd2FzIG1hY2hzdCwgd2VubiBlaW4g
QXV0b3IgaGVpcmF0ZXQgdW5kIER1IGRlbiBOYW1lbgrDpG5kZXJzdD8gRGll
IELDvGNoZXIsIGRpZSBlciB2b3Igc2VpbmVyIFZlcmhlaXJhdHVuZyBnZXNj
aHJpZWJlbiBoYXQsCm3DvHNzZW4gZWlnZW50bGljaCBub2NoIHVudGVyIHNl
aW5lbSBhbHRlbiBBdXRvcmVubmFtZW4genUgZmluZGVuIHNlaW4sCmRlbm4g
ZGllc2VyIHN0ZWh0IGphIGF1Y2ggYXVmIGRlbiBCw7xjaGVybi4gTnVuIGdp
YnQgZXMgYWJlciBiZXJlaXRzCmVpbmVuIGFuZGVyZW4gQXV0b3JlbiBtaXQg
ZGVtIG5ldWVuIE5hbWVuPyEgV2FzIGRhbm4/CgpFcmdvOiBzb2xjaGUgRWlu
c2NocsOkbmt1bmdlbiB3ZXJkZW4gRGljaCBnYXJhbnRpZXJ0IGlyZ2VuZHdh
bm4gYmVpw59lbi4KRXMgaXN0IGd1dCwgd2VubiBlcyBudXIgZWluZW4gRWlu
dHJhZyBmw7xyIGVpbmUgcGh5c2lrYWxpc2NoZSBFbnRpdMOkdApnaWJ0LCBh
YmVyIGVzIGlzdCBrZWluZSBndXRlIElkZWUsIHp1IHZlcnN1Y2hlbiwgZXR3
YXMgYWxzICJ1bmlxdWUiIHp1CmRlZmluaWVyZW4sIHdhcyBvZmZlbnNpY2h0
bGljaCBpbSByZWFsZW4gTGViZW4gbmljaHQgdW5pcXVlIGlzdC4gSW0KTmFt
ZW5zcmVnaXN0ZXIgc2FndCBqYSBhdWNoIG5pZW1hbmQgIk5laW4sIHNpZSBr
w7ZubmVuIGlociBLaW5kIG5pY2h0CkhhbnMgbmVubmVuLCBkZW5uIGVzIGdp
YnQgc2Nob24gZWluZW4gSGFucyBNw7xsbGVyIGF1ZiBkZXIgV2VsdCIuCgpW
ZXJzdWNoZSBuaWUsIGluIGRlciBEYXRlbmJhbmsgZXR3YXMgZGFyenVzdGVs
bGVuLCB2b24gZGVtIER1IGluIGRlcgpSZWFsaXTDpHQgc2Nob24gd2Vpw590
LCBkYcOfIER1IGVzIG5pY2h0IGdhcmFudGllcmVuIGthbm5zdCAoaW4gZGVt
IEZhbGwKRWluZWluZGV1dGlna2VpdCBlaW5lcyBOYW1lbnMpLgoKRsO8ciBl
aW5lIElTQk4gc2VoZSBpY2ggZGFzIGVpbiwgZGEgZGllc2UgamEgcGVyIERl
ZmluaXRpb24gZWluZGV1dGlnCmlzdC4gQWJlciBmw7xyIGFuZGVyZSBNZXJr
bWFsZT8gSXJnZW5kd2FubiBiZWnDn3QgZXMgRGljaCB1bmQgRHUgbXXDn3Qg
ZXMKd2llZGVyIMOkbmRlcm4uCgpEZXN3ZWdlbiBuaW1tdCBtYW4gamEgYXVj
aCBlaWdlbnRsaWNoIGltbWVyIGVpbiAia8O8bnN0bGljaGVzIiBBdHRyaWJ1
dAphbHMgUEssIHdlaWwgbWFuIGRhZsO8ciBkaWUgRWluZGV1dGlna2VpdCBn
YXJhbnRpZXJlbiBrYW5uLiBGw7xyIGFuZGVyZXMKaXN0IGRhcyBvZnQgc2No
d2llcmlnLgoKY3VnCgoKT24gMTEvMTAvMDYsIEFuZHJlYXMgQmF1ZXIgPGFu
ZHJlYXNfYmF1ZXJAYXJjb3IuZGU+IHdyb3RlOgo+IEhhbGxvIEd1aWRvLAo+
ID4+QmlzdCBEdSBzaWNoZXIsIGRhw58gRHUgZGFzIHdpcmtsaWNoIHdpbGxz
dD8gRsO8ciBtaWNoIGtsaW5ndCBkYXMgbmFjaCBlaW5lcgo+IHppZW1saWNo
IHNjaGxlY2h0ZW4gSWRlZS4gQXXDn2VyIG5hdMO8cmxpY2gsIER1IGthbm5z
dCBHQVJBTlRJRVJFTiwgZGHDnyBEdSBuaWUKPiA+PmVpbmUgUGVyc29uIGF1
Zm5laG1lbiB3aWxsc3QsIGRpZSBkZW4gQmVkaW5ndW5nZW4gbmljaHQgZ2Vu
w7xndC4KPiA+Pk51ciBzbyBhdXMgSW50ZXJlc3NlOiB3YXJ1bSBzb2xsIGRh
cyBzbyBzZWluPwo+IE5hLCBpY2ggd2lsbCBEb3BwZWxlaW50csOkZ2UgdmVy
bWVpZGVuLiBWaWVsbGVpY2h0IHNvbGx0ZSBkYXMgRmVsZCB0aXRsZSBkZXIK
PiBhbmRlcmVuIHRfQm9va3MgVGFiZWxsZSBhdWNoIG5vY2ggaW4gQ09OU1RS
QUlOVCBVTklRVUUKPiBtaXRlaW5iZXpvZ2VuIHdlcmRlbi4gRGFzIHfDpHJl
IGRhbm4gc2Nob24gZWluIHNlaHIgZ3Jvw59lciBadWZhbGwsIHdlbm4gZXMK
PiB0YXRzw6RjaGxpY2ggMiBpZGVudGlzY2hlIEF1dG9yZW5uYW1lbiwgTmFj
aC0gVW5kIFZvcm5hbWUsIHVuZCBub2NoCj4gMiBpZGVudGlzY2hlIEJ1Y2h0
aXRlbCBnw6RiZSwgd29kdXJjaCBlaW4gQXV0b3IgZGFubiBkdXJjaCBkaWVz
ZXMgVU5JUVVFCj4gZWxlbWluaWVydCB3w7xyZGUuCj4KPiBEaWUgdF9ib29r
cyBzaWVodCBzbyBhdXM6Cj4KPiBjcmVhdGUgdGFibGUgdF9ib29rcwo+ICgK
PiAgICAgICAgIGJvb2tpZCAgICAgICAgICBpbnQ0ICAgICAgICAgICAgcHJp
bWFyeSBrZXkKPiAgICAgICAgICAgICAgICAgICAgICAgICBkZWZhdWx0IG5l
eHR2YWwoJ3NfYm9va3MnKSwKPiAgICAgICAgIGF1dGhvcmlkICAgICAgICBp
bnQ0ICAgICAgICAgICAgbm90IG51bGwKPiAgICAgICAgICAgICAgICAgICAg
ICAgICByZWZlcmVuY2VzIHRfYXV0aG9ycyhhdXRob3JpZCkKPiAgICAgICAg
ICAgICAgICAgICAgICAgICBvbiBkZWxldGUgY2FzY2FkZSwKPgo+ICAgICAg
Rk9SRUlHTiBLRVkgKGF1dGhvcmlkKSBSRUZFUkVOQ0VTIHRfYXV0aG9ycyAo
YXV0aG9yaWQpIE9OIFVQREFURQo+IENBU0NBREUgT04gREVMRVRFIENBU0NB
REUsCj4gICAgICB0aXRsZSAgICAgICAgICAgICAgICB2YXJjaGFyKDEyNykg
IG5vdCBudWxsLAo+Cj4gICAgICBzdWJ0aXRsZSAgICAgICAgdmFyY2hhcigy
NTUpCj4KPiApOwo+Cj4KPiBPbiAxMS8xMC8wNiwgQW5kcmVhcyBCYXVlciA8
YW5kcmVhc19iYXVlckBhcmNvci5kZT4gd3JvdGU6Cj4gPiBIYWxsbyBORywK
PiA+Cj4gPiB1bSBEb3BwZWxlaW50csOkZ2UgaW4gZGVyIHBvc3RncmVzIERC
IHp1IHZlcm1laWRlbiwgaGFiZSBpY2ggaW4gbWVpbmVtCj4gPiBjcmVhdGUg
dGFibGUgZWluZ2Vmw7xndDoKPiA+IENPTlNUUkFJTlQgY29uMSBVTklRVUUg
KGxhc3RuYW1lLGZpcnN0bmFtZSkKPiA+Cj4gPiBXaWUga2FubiBpY2ggZGVu
IFVOSVFVRSBCZWZlaGwgc2NocmVpYmVuLCBkYXNzIGRpZSBEYXRlbnPDpHR6
ZSBuaWNodAo+ID4gZG9wcGVsdCBzaW5kLCBiZWkgZGVuZW4gZGllIEJlZGlu
Z3VuZyBlcmbDvGxsdCBpc3QsIGRhc3MgZGVyIGxhc3RuYW1lCj4gPiAidW5k
IiBkZXIgZmlyc3RuYW1lIGlkZW50aXNjaCBzaW5kLCBhbHNvIHdlbm4gaW4g
ZWluZXIgWmVpbGUgQmF1ZXIKPiA+IEFuZHJlYXMgYWxzIGxhc3QtIHVuZCBm
aXJzdG5hbWUgc3RlaHQsIGRhc3MgQmF1ZXIgdW5kIEFuZHJlYXMgYWxzCj4g
PiBmaXJzdC0gdW5kIGxhc3RuYW1lIG5pY2h0IG5vY2ggbWFsIGluIGVpbmVy
IFplaWxlIGRlciBUYWJlbGxlCj4gPiBlaW5nZXRyYWdlbiB3aXJkLiAgRXMg
a2FubiBqYSBhdWNoIGVpbmUgYW5kZXJlIFBlcnNvbiBkZW4gZ2xlaWNoZW4K
PiA+IGxhc3RuYW1lLCBhYmVyIGVpbmVuIGFuZGVyZW4gZmlyc3RuYW1lIGhh
YmVuLiBEYSB3w7xyZGUgZGVyIENPTlNUUkFJTlQKPiA+IGNvbjEgVU5JUVVF
IChsYXN0bmFtZSxmaXJzdG5hbWUpIGphIHNjaG9uIGRlbiBsYXN0bmFtZSBu
aWNodCB6dWxhc3NlbiwKPiA+IG9kZXIgbGllZyBpY2ggZGEgZmFsc2NoPyBH
ZWh0IGRhcyDDvGJlcmhhdXB0IG1pdCBVTklRVUUsIG1pdCBlaW5lciAmCj4g
PiBWZXJrbsO8cGZ1bmcgdm9uIGRlbiBGZWxkZXJuPwo+ID4gRGllIHBxLXF1
ZXJ5IEZlaGxlcm1lbGR1bmcgdm9uIHBocDoKPiA+IFdhcm5pbmc6IHBnX3F1
ZXJ5KCkgW2Z1bmN0aW9uLnBnLXF1ZXJ5XTogUXVlcnkgZmFpbGVkOiBFUlJP
UjoKPiA+IGR1cGxpY2F0ZSBrZXkgdmlvbGF0ZXMgdW5pcXVlIGNvbnN0cmFp
bnQgImNvbjEiIGluIEthbm4gbWFuIGRpZQo+ID4gYWJzY2hhbHRlbj8KPiA+
Cj4gPgo+ID4gR3LDvMOfZQo+ID4gQW5kcmVhcwo+ID4KPiA+Cj4gPgo+ID4K
PiA+IGNyZWF0ZSB0YWJsZSB0X2F1dGhvcnMKPiA+ICgKPiA+ICAgICAgICAg
YXV0aG9yaWQgICAgICAgIGludDQgICAgICAgICAgICBwcmltYXJ5IGtleQo+
ID4gICAgICAgICAgICAgICAgICAgICAgICAgZGVmYXVsdCBuZXh0dmFsKCdz
X2F1dGhvcnMnKSwKPiA+ICAgICAgICAgbGFzdG5hbWUgICAgICAgICAgICAg
ICAgdmFyY2hhcigzMSkgICAgIG5vdCBudWxsLAo+ID4gICAgICAgICBmaXJz
dG5hbWUgICAgICAgICAgICAgICB2YXJjaGFyKDMxKSAgICAgbm90IG51bGws
Cj4gPiAgICAgICAgIENPTlNUUkFJTlQgY29uMSBVTklRVUUgKGxhc3RuYW1l
LGZpcnN0bmFtZSkKPiA+Cj4gPiApOwo+Cj4gR3LDvMOfZQo+IEFuZHJlYXMK
Pgo+CgoKLS0gClBvc3RncmVTUUwgQm9vdGNhbXAsIEJpZyBOZXJkIFJhbmNo
IEV1cm9wZSwgTm92IDIwMDYKaHR0cDovL3d3dy5iaWduZXJkcmFuY2guY29t
L25ld3MvMjAwNi0wOC0yMS5zaHRtbAoKLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tKGVuZCBvZiBicm9hZGNhc3QpLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tClRJUCAyOiBEb24ndCAna2lsbCAtOScgdGhlIHBvc3RtYXN0ZXIK

Hallo Andreas,
> Andreas Kretschmer schrieb:
> Mach einen Unique Index auf beide Spalten, das wirkt.
>Aber ich würde nicht so sicher sein, daß Vor- und Zuname
> nicht doppelt vorkommen können.
Dank Dir. Wie kann man ein UNIQUE Index der beiden Spalten lastname
und firstname mit der Spalte title einer Büchertabelle verbinden. Wenn
der Büchertitel auch noch gleich wäre..........wäre das schon ein R=
iesenzufall.

Grüße
Andreas



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

QWJlciBEdSBnZWhzdCBkYW5uIGRlbm5vY2ggdm9uIGVpbmVyIHZvbiBEaXIg
Z2VtYWNodGVuIEFubmFobWUgYXVzLiBEdQprYW5uc3QgZGFzIGltIHJlYWxl
biBMZWJlbiBuaWNodCBnYXJhbnRpZXJlbi4KCldpZSBzY2hvbiBnZXNhZ3Q6
IFJlZ2VsIE5yLiAxIGbDvHIgbWljaCBpc3QgaW1tZXIsIG5pZSB6dSB2ZXJz
dWNoZW4sIGluCmRlciBEYXRlbmJhbmsgenUgZ2FyYW50aWVyZW4sIHdhcyBp
Y2ggaW4gZGVuIERhdGVuLCBkaWUgcmVpbmtvbW1lbiwKbmljaHQgZ2FyYW50
aWVyZW4ga2Fubi4gRGFzIGlzdCBlaW5mYWNoIHNjaGxlY2h0ZXMgTW9kZWxs
aWVyZW4uCkdhcmFudGllcmUgaW1tZXIgbnVyIERpbmdlLCBkaWUgZ2FyYW50
aWVyYmFyIHNpbmQsIG5pZW1hbHMgc29sY2hlLCBkaWUKImVpbmVzIGdyb8Of
ZW4gWnVmYWxscyBiZWTDvHJmZW4sIHVtIGRvY2ggYXVmenV0cmV0ZW4iLiBE
ZW5uIG5hY2ggTXVycGh5CnRhdWNodCBkZXIgRmFsbCBnZW5hdSBkYW5uIGF1
Ziwgd2VubiBEdSBpaG4gYW0gd2VuaWdzdGVuIGdlYnJhdWNoZW4Ka2FubnN0
LgoKY3VnCgpPbiAxMS8xMC8wNiwgQW5kcmVhcyBCYXVlciA8YW5kcmVhc19i
YXVlckBhcmNvci5kZT4gd3JvdGU6Cj4gSGFsbG8gQW5kcmVhcywKPiA+IEFu
ZHJlYXMgS3JldHNjaG1lciBzY2hyaWViOgo+ID4gTWFjaCBlaW5lbiBVbmlx
dWUgSW5kZXggYXVmIGJlaWRlIFNwYWx0ZW4sIGRhcyB3aXJrdC4KPiA+QWJl
ciBpY2ggd8O8cmRlIG5pY2h0IHNvIHNpY2hlciBzZWluLCBkYcOfIFZvci0g
dW5kIFp1bmFtZQo+ID4gbmljaHQgZG9wcGVsdCB2b3Jrb21tZW4ga8O2bm5l
bi4KPiBEYW5rIERpci4gV2llIGthbm4gbWFuIGVpbiBVTklRVUUgSW5kZXgg
ZGVyIGJlaWRlbiBTcGFsdGVuIGxhc3RuYW1lCj4gdW5kIGZpcnN0bmFtZSBt
aXQgZGVyIFNwYWx0ZSB0aXRsZSBlaW5lciBCw7xjaGVydGFiZWxsZSB2ZXJi
aW5kZW4uIFdlbm4KPiBkZXIgQsO8Y2hlcnRpdGVsIGF1Y2ggbm9jaCBnbGVp
Y2ggd8OkcmUuLi4uLi4uLi4ud8OkcmUgZGFzIHNjaG9uIGVpbiBSaWVzZW56
dWZhbGwuCj4KPiBHcsO8w59lCj4gQW5kcmVhcwo+Cj4KPgo+IC0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLShlbmQgb2YgYnJvYWRjYXN0KS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQo+IFRJUCA0OiBIYXZlIHlvdSBzZWFyY2hl
ZCBvdXIgbGlzdCBhcmNoaXZlcz8KPgo+ICAgICAgICAgICAgICAgIGh0dHA6
Ly9hcmNoaXZlcy5wb3N0Z3Jlc3FsLm9yZwo+CgoKLS0gClBvc3RncmVTUUwg
Qm9vdGNhbXAsIEJpZyBOZXJkIFJhbmNoIEV1cm9wZSwgTm92IDIwMDYKaHR0
cDovL3d3dy5iaWduZXJkcmFuY2guY29tL25ld3MvMjAwNi0wOC0yMS5zaHRt
bAoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKGVuZCBvZiBicm9hZGNh
c3QpLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClRJUCA5OiBJbiB2ZXJz
aW9ucyBiZWxvdyA4LjAsIHRoZSBwbGFubmVyIHdpbGwgaWdub3JlIHlvdXIg
ZGVzaXJlIHRvCiAgICAgICBjaG9vc2UgYW4gaW5kZXggc2NhbiBpZiB5b3Vy
IGpvaW5pbmcgY29sdW1uJ3MgZGF0YXR5cGVzIGRvIG5vdAogICAgICAgbWF0
Y2gK

A. Kretschmer <andreas.kretschmer [at] schollglas.com> wrote:
> (va qrz rvara Qbccry zhßgr rvar mjnatfurvengra, vz naqrera jheqr
> wrznaq ragynffra)

lol. Aber das Problem kenn ich :)

Gruß
Tobias


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Testantwort, weil bei mir, wenn ich von [at] work aus maile, das Subject
kapott geht. Mal sehen, wie es von zu Hause aus ist. Sorry für den
Spam...


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." (unknow)
Kaufbach, Saxony, Germany, Europe. N 51.05082=B0, E 13.56889=
=B0

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Sorry, noch ein Test.

Hab diesmal den Umlaut zu ae gewandelt.


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." (unknow)
Kaufbach, Saxony, Germany, Europe. N 51.05082=B0, E 13.56889=
=B0

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo [at] postgresql.org so that your
message can get through to the mailing list cleanly

ich schreib mal in diesen thread mit rein, weil es vom thema passt.
also folgende situation:

-tabelle mit nutzerinfos
-nutzer hat name und vorname(ich nehme keine unique dafuer, koennte ja
durchaus 2 personen mit gleichen geben)
-nutzer hat loginname <- dieser koennte/muesste unique sein
-tabelle hat noch ein archivbit fuer loeschen von nutzern
-diese nutzer sollen vorhanden bleiben um zum bleistift verknuepfte
aenderungen dokumentieren zu koennen
-dies kollediert aber mit dem unique des loginnames, dieweil der loginname
eines
geloeschten accounts, ja wiederverwendet werden koennte

wie wuerdet(macht) ihr das realisieren?
mit archivbit und trigger als unique-pruefung?
mit archivtabelle......?

ist eher eine konzeptionelle frage, aber niemand
....also ich weis alles und warum das rad 3x erfinden? :D








---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

rene hankel wrote:
> -nutzer hat loginname <- dieser koennte/muesste unique sein
> -tabelle hat noch ein archivbit fuer loeschen von nutzern
> -diese nutzer sollen vorhanden bleiben um zum bleistift verknuepfte
> aenderungen dokumentieren zu koennen
> -dies kollediert aber mit dem unique des loginnames, dieweil der
> loginname eines
> geloeschten accounts, ja wiederverwendet werden koennte

Dann halt Unique Constraint auf beide Spalten zusammen setzen.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Nabnd zusammen,

Peter Eisentraut <peter_e [at] gmx.net> wrote:
> rene hankel wrote:
>> -nutzer hat loginname <- dieser koennte/muesste unique sein
>> -tabelle hat noch ein archivbit fuer loeschen von nutzern
>> -diese nutzer sollen vorhanden bleiben um zum bleistift verknuepfte
>> aenderungen dokumentieren zu koennen
>> -dies kollediert aber mit dem unique des loginnames, dieweil der
>> loginname eines
>> geloeschten accounts, ja wiederverwendet werden koennte

wie willst du die dann zuordnen? gibt es noch einen (künstlichen) prima=
ry
key, z.B. eine nutzer-nr?

> Dann halt Unique Constraint auf beide Spalten zusammen setzen.

hm, dann kann ja nur je ein gelöschter Nutzer mit dem Namen existieren.
Wie wärs denn mit einem partial index mit unique?

CREATE TABLE "playground"."table1" (
"name" VARCHAR,
"del" BOOLEAN NOT NULL
) WITH OIDS;

CREATE UNIQUE INDEX "table1_idx" ON "playground"."table1"
USING btree ("name")
WHERE (del =3D false);

hth
Tobi


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Tobias Bußmann wrote:
> > Dann halt Unique Constraint auf beide Spalten zusammen setzen.
>
> hm, dann kann ja nur je ein gelöschter Nutzer mit dem Namen

Wenn er die alten Namen behalten will, weil noch Daten drauf verweisen,
wird es wohl nicht sinnvoll sein, mehrere gleiche alte Namen zu haben.
Sonst muss er sich ein verändertes Konzept für die Namensarchivierung=

überlegen.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

>
> Nabnd zusammen,
>
> Peter Eisentraut <peter_e [at] gmx.net> wrote:
> > rene hankel wrote:
> >> -nutzer hat loginname <- dieser koennte/muesste unique
> sein -tabelle
> >> hat noch ein archivbit fuer loeschen von nutzern -diese
> nutzer sollen
> >> vorhanden bleiben um zum bleistift verknuepfte aenderungen
> >> dokumentieren zu koennen -dies kollediert aber mit dem unique des
> >> loginnames, dieweil der loginname eines geloeschten accounts, ja
> >> wiederverwendet werden koennte
>
> wie willst du die dann zuordnen? gibt es noch einen
> (künstlichen) primary key, z.B. eine nutzer-nr?


logo klar, muss ich solche selbstverstaendlichkeiten euch explizit
aufschreiben?
ich denk nicht ;)


>
> > Dann halt Unique Constraint auf beide Spalten zusammen setzen.
>
> hm, dann kann ja nur je ein gelöschter Nutzer mit dem Namen
> existieren.


richtig und genau das moechte ich nicht! 2 oder x nutzer mit gleichen namen
sind mir schnuppe,
denn der loginname ist die wirklich eindeutig sache. name vorname sind nur
naehere erlaeuterungen
fuer das system und nicht wirklich relevant


> Wie wärs denn mit einem partial index mit unique?
>
> CREATE TABLE "playground"."table1" (
> "name" VARCHAR,
> "del" BOOLEAN NOT NULL
> ) WITH OIDS;
>
> CREATE UNIQUE INDEX "table1_idx" ON "playground"."table1"
> USING btree ("name")
> WHERE (del =3D false);
>


was? ich kann einen unique index mit where einschraenken? habt ihr andere=

buecher als ich? ich wuerde nicht mal auf die idee kommen das sowas moeglich
ist!

ich sehe schon, ich stehe noch vor dem anfang etwas ueber postgres zu
koennen.
:((


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq