ich muss zugeben das ich langsam aber sicher, absolut keine ahnung mehr habe
wo ich suchen soll.
ich habe mir auch die tabellenrechte mit \dp in psql angesehen - alles
normal.

ich meine die abfrage, obwohl sie vom system kommen muss(von michse ist sie
nicht ;-))
ist ja logisch.
> SELECT 1 FROM ONLY "anlagen"."tbl_anlagentyp" x WHERE "id" =3D $1 FOR SHA=
RE
OF x

ich gehe stark davon aus, das es die abfrage zum checken des CONSTRAINTS
ist. bis
dato ok, dieweil ja meine gruppenrole selectrechte hat!

ich muss zugeben, das ich befürchte, das mein authenfizierung das problem
ist. denn
1.) selbst die abfrage als superuser bringt die selbe fehlermeldung
2.) wenn ich der role PUBLIC zugriff gewaehre funzt alles

deswegen die frage, wie wird sql-technisch die authentifizierung
durchgefuehrt?
im augenblick mach ich das so

> SET ROLE foo;
> INSERT INTO anlagen.tbl_anlage
> ( id, anlagentyp_id, hersteller_id, ...)
> VALUES
> ( 72006008, 17, 7, ... );

ich habe das gefühl, das die gruppenrole einfach garnicht mehr aktiv ist
beim insert.
ich bräuchte wirklich dringend eine lösung, auch wenns heisst das ich s=
chuld
bin :-(




*wenn ich glück habe, landet das im richtigen thread*

----- AVT Verkehrstechnik ------------------

AVT Verkehrstechnik
NL Nordhausen
Ren=E9 Hankel
Industrieweg 11
99734 Nordhausen, Germany
eMail: rene.hankel [at] avt-verkehrstechnik.de
'''''' tel.: (03631) 468843
(o)(o)
--ooo--(__)--ooo----------------------------


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

am 01.06.2006, um 12:23:44 +0200 mailte rene hankel folgendes:
> ich muss zugeben das ich langsam aber sicher, absolut keine ahnung mehr=
habe
> wo ich suchen soll.

Geht mir auch so, der Thread ist ja schon einen Monat alt ;-)


> ich habe mir auch die tabellenrechte mit \dp in psql angesehen - alles
> normal.

Hast Du die Anregung von Walter Haslbeck, 3. Mai, mal durchdacht?


> ich bräuchte wirklich dringend eine lösung, auch wenns heisst das i=
ch schuld
> bin :-(

Ja ja, schon gut. Warum frickelst Du meinen Namen ins Subject?


> *wenn ich glück habe, landet das im richtigen thread*

Nein. Bei sowas verläßt man sich auch nicht auf das Glück, sondern
verwendet einen gescheiten Mailclient.


Andreas
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47215, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=3D=3D=3D Schollglas Unternehmensgruppe =3D=3D=3D

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

> von A. Kretschmer
> Geht mir auch so, der Thread ist ja schon einen Monat alt ;-)

was soll ich sagen, das problem loest sich nicht in luft auf!
tatsache ist, das ding ist grundlage eines groesseren projektes und
kann sicherlich auch ohne differenzierte berechtigung laufen, aber
das kanns doch nicht sein!? oder etwa nicht?


> von A. Kretschmer
> Hast Du die Anregung von Walter Haslbeck, 3. Mai, mal durchdacht?

er hat voellig recht mit der referenzierung, jedoch hat die role die
select-rechte
ich habe zwar noch nicht viel ahnung von poschtgres, aber das hatte ich vor
dem
posting schon gecheckt und gesetzt! wirklich! ;-)
trotzdem interessiert es postgres nicht. ich meine, arbeitet denn hier
keiner
mit rolen oder funzt das bei euch einfach nur richtig? ich kann nur
vermuten,
wie ich schon sagte, das das dieses select NICHT mit den berichtigungen der
gruppenrole laeuft und so vorn baum laeuft. wieso aber nimmt er nicht die=

grupperolle, die ich vorher gesetzt habe. wie macht ihr das? doch auch nicht
anders!?
ala
SET ROLE foo;
INSERT...;


> von A. Kretschmer
> Ja ja, schon gut. Warum frickelst Du meinen Namen ins Subject?

war keine absicht, bin aber schuld, gebe ich zu.
cut und paste ohne gucke da schau und schwupps da isser :-(
bin schuldig


> von A. Kretschmer
> Nein. Bei sowas verläßt man sich auch nicht auf das Glück,
> sondern verwendet einen gescheiten Mailclient.

leider bin ich schuld, ich habe die alten mehls vor wut geloescht weil
nichts
geholfen hat. ihr habt nix damit zu tun.


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

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

am 01.06.2006, um 14:36:19 +0200 mailte rene hankel folgendes:
>
>
> > von A. Kretschmer
> > Geht mir auch so, der Thread ist ja schon einen Monat alt ;-)
>
> was soll ich sagen, das problem loest sich nicht in luft auf!

Ich hatte das nach der langen Zeit erhofft ;-)


> tatsache ist, das ding ist grundlage eines groesseren projektes und
> kann sicherlich auch ohne differenzierte berechtigung laufen, aber
> das kanns doch nicht sein!? oder etwa nicht?

42.


> trotzdem interessiert es postgres nicht. ich meine, arbeitet denn hier
> keiner
> mit rolen oder funzt das bei euch einfach nur richtig? ich kann nur
> vermuten,

Ich schätze mal wild, daß mastermind damit sehr intensiv arbeitet. Du
wirst ihn nicht kennen, er ist mehr in #postgresql und #postgresql-de
aktiv. Hast Du IRC-Zugang?


> grupperolle, die ich vorher gesetzt habe. wie macht ihr das? doch auch =
nicht

Ich nutze es nicht, kein Bedarf bisher.


> leider bin ich schuld, ich habe die alten mehls vor wut geloescht weil
> nichts
> geholfen hat. ihr habt nix damit zu tun.

Da bin ich aber erleichtert...


Mit freundlichen Grüßen, A. Kretschmer
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47215, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=3D=3D=3D Schollglas Unternehmensgruppe =3D=3D=3D

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

http://archives.postgresql.org

> > > von A. Kretschmer
> > > Geht mir auch so, der Thread ist ja schon einen Monat alt ;-)
> >
> > was soll ich sagen, das problem loest sich nicht in luft auf!
>
> Ich hatte das nach der langen Zeit erhofft ;-)

dann sind wir schon 2 :(


> > tatsache ist, das ding ist grundlage eines groesseren projektes und
> > kann sicherlich auch ohne differenzierte berechtigung laufen, aber das=

> > kanns doch nicht sein!? oder etwa nicht?
>
> 42.

die aw ist sehr gut, aber wenig hilfreich :(


> > trotzdem interessiert es postgres nicht. ich meine, arbeitet denn hier=

> > keiner mit rolen oder funzt das bei euch einfach nur richtig? ich kann=

> > nur vermuten,
>
> Ich schätze mal wild, daß mastermind damit sehr intensiv
> arbeitet. Du wirst ihn nicht kennen, er ist mehr in
> #postgresql und #postgresql-de aktiv. Hast Du IRC-Zugang?

IRZ? was ist denn das? :D
also den zugang koennte ich sicherlich haben wenn ichs benoetige, zur zeit=

aber habe ich keinen.
trotzdem, was kann ich tun um mister mastermind zu befragen? :)


> > grupperolle, die ich vorher gesetzt habe. wie macht ihr das? doch auch=

> > nicht
>
> Ich nutze es nicht, kein Bedarf bisher.

mmmh, ich meine ich geh ja auch ueber funktionen/stored proc, so das ich
diese expliziten sicherheit nicht brauche, jedoch bin ich mit einer halbe=

loesung nicht zufrieden. du kennst doch das zitat: '...tut es oder tu es
nicht, es gibt kein versuchen...'
ich hasse halbe loesungen *hassss...doppelhasss.....*


> > leider bin ich schuld, ich habe die alten mehls vor wut geloescht
> > weil nichts geholfen hat. ihr habt nix damit zu tun.
>
> Da bin ich aber erleichtert...

und ich erst :D


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

am 01.06.2006, um 15:46:44 +0200 mailte rene hankel folgendes:
> > Ich schätze mal wild, daß mastermind damit sehr intensiv
> > arbeitet. Du wirst ihn nicht kennen, er ist mehr in
> > #postgresql und #postgresql-de aktiv. Hast Du IRC-Zugang?
>
> IRZ? was ist denn das? :D
> also den zugang koennte ich sicherlich haben wenn ichs benoetige, zur z=
eit
> aber habe ich keinen.
> trotzdem, was kann ich tun um mister mastermind zu befragen? :)

IRC. Internet Relay Chat.
http://de.wikipedia.org/wiki/IRC-Channel

Gugg mal unter http://pgug.de/community/community.php. Du brauchst einen
Client dazu, gibt es aber wie Sand am Meer. Ich nutze irssi.


Dor plaudert man dann halt:

14:11 < McKnight> am einfachsten ist wohl, die anderen in eine (temp) tab=
le einzufügen und die DB mit einem WHERE NOT IN oder EXCEPT oder so zu =
befragen...
14:13 < alice|wl_> wie, die bestehtnden benutzer in eine table schreiben?
14:14 < alice|wl_> hmm, dann könnt ich sie wohl auf die nicht existent=
en beschränken und löschen
14:14 < McKnight> naja, die jeweils fehlenden. Ein "x was nicht in y ist"=
ist mit der bash nicht so einfach. egrep -v a|b|c ... oder Dateien aus e=
inem Set
touchen und aus dem anderen Löschen udn gucken was ü=
brig bleibt oder so.
14:15 < McKnight> daher: wenn du die eine Hälfte eh schon in der DB has=
t und die andere leicht reinschreiben kannst, es ausserdem nur einmal bra=
uchst, ist es
bequemer die Datenbank das "x was nicht in y" rausfinde=
n zu lassen



Andreas
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47215, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=3D=3D=3D Schollglas Unternehmensgruppe =3D=3D=3D

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

--On Donnerstag, Juni 01, 2006 12:23:44 +0200 rene hankel
<rene.hankel [at] avt-verkehrstechnik.de> wrote:

> ich muss zugeben das ich langsam aber sicher, absolut keine ahnung mehr
> habe wo ich suchen soll.
> ich habe mir auch die tabellenrechte mit \dp in psql angesehen - alles
> normal.
>
> ich meine die abfrage, obwohl sie vom system kommen muss(von michse ist
> sie nicht ;-))
> ist ja logisch.
>> SELECT 1 FROM ONLY "anlagen"."tbl_anlagentyp" x WHERE "id" =3D $1 FOR SH=
ARE
> OF x

Ich habe den Einstieg in diesen Thread irgendwie verpasst, aber ich vermute=

den
Fehler hier:

--------------8<-----------------------------------------------------------=
-------------
CREATE TABLE sonstiges.tbl_favoriten
(
-- Vererbt: erstellt_am timestamp DEFAULT ('now'::text)::timestamp(6)
without time zone,
-- Vererbt: erstellt_benutzer_id int4 DEFAULT 0,
-- Vererbt: aenderung_am timestamp,
-- Vererbt: aenderung_benutzer_id int4 DEFAULT 0,
-- Vererbt: geloescht_am timestamp,
-- Vererbt: geloescht_benutzer_id int4 DEFAULT 0,
-- Vererbt: geloescht bool DEFAULT false,
id int8 NOT NULL DEFAULT
nextval(('sonstiges.seq__tbl_favoriten__id'::text)::regclass ), -- primarykey
anlage_id int8 NOT NULL, -- foreignkey -> tbl_anlage.id
benutzer_id int8 NOT NULL, -- foreignkey -> tbl_benutzer.id
CONSTRAINT pkey__tbl_favoriten__id PRIMARY KEY (id),
CONSTRAINT fkey__tbl_favoriten__anlage_id FOREIGN KEY (anlage_id)
REFERENCES anlagen.tbl_anlage (id) MATCH SIMPLE
ON UPDATE RESTRICT ON DELETE RESTRICT,
CONSTRAINT fkey__tbl_favoriten__benutzer_id FOREIGN KEY (benutzer_id)
REFERENCES benutzer.tbl_benutzer (id) MATCH SIMPLE
ON UPDATE RESTRICT ON DELETE RESTRICT
) INHERITS (virtual.tbl_tupelaenderung)
WITHOUT OIDS;

ALTER TABLE sonstiges.tbl_favoriten OWNER TO usr_dbavt_admin;
--------------8<-----------------------------------------------------------=
-------------

Der neue Besitzer der Tabelle tbl_favoriten hat keine Leseberechtigung auf
tbl_anlage, was notwendig ist, um den Foreign Key Check auszuführen
(FK-Checks
sind RI-Trigger die im Context des Tabellen-Owners ausgeführt werden).

Man kann dies aber nur schwer nachvollziehen, bei mir passiert's nur in
dieser Reihenfolge
(wenn das REVOKE für die Rolle test ganz unten steht):

CREATE SCHEMA bernd;
CREATE TABLE A(id INTEGER NOT NULL PRIMARY KEY);
CREATE TABLE B(id INTEGER NOT NULL PRIMARY KEY, name
TEXT NOT NULL, FOREIGN KEY(id) REFERENCES A(id) MATCH SIMPLE ON UPDATE
RESTRICT ON DELETE RESTRICT);

REVOKE ALL ON a FROM bhe;
REVOKE ALL ON b FROM bhe;
GRANT SELECT ON a to bhe;

GRANT SELECT,INSERT,DELETE ON b to bhe;
ALTER TABLE A OWNER TO test;

INSERT INTO A VALUES (1);
INSERT INTO A VALUES (2);
INSERT INTO A VALUES (3);
INSERT INTO A VALUES (4);
GRANT USAGE on SCHEMA bernd TO bhe;

GRANT ALL on SCHEMA bernd TO bhe;
GRANT ALL ON SCHEMA bernd to test;
REVOKE ALL ON a FROM test;

SET ROLE bhe;
INSERT INTO bernd.b VALUES (2, '');

ERROR: permission denied for relation a
CONTEXT: SQL statement "SELECT 1 FROM ONLY "bernd"."a" x WHERE "id" =3D $1
FOR SHARE OF x"

Da ich grade zu müde bin, mir das genauer anzusehen, verschiebe ich das a=
uf
morgen. Es
sollte aber nun hoffentlich klar sein, wo das Problem liegt.

--
Thanks

Bernd

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

> Ich habe den Einstieg in diesen Thread irgendwie verpasst,
> aber ich vermute den Fehler hier:
>
> --------------8<----------------------------------------------
> --------------------------
> CREATE TABLE sonstiges.tbl_favoriten
> (
> -- Vererbt: erstellt_am timestamp DEFAULT
> ('now'::text)::timestamp(6)
> without time zone,
> -- Vererbt: erstellt_benutzer_id int4 DEFAULT 0,
> -- Vererbt: aenderung_am timestamp,
> -- Vererbt: aenderung_benutzer_id int4 DEFAULT 0,
> -- Vererbt: geloescht_am timestamp,
> -- Vererbt: geloescht_benutzer_id int4 DEFAULT 0,
> -- Vererbt: geloescht bool DEFAULT false,
> id int8 NOT NULL DEFAULT
> nextval(('sonstiges.seq__tbl_favoriten__id'::text)::regclass ),
> -- primarykey
> anlage_id int8 NOT NULL, -- foreignkey -> tbl_anlage.id
> benutzer_id int8 NOT NULL, -- foreignkey -> tbl_benutzer.id
> CONSTRAINT pkey__tbl_favoriten__id PRIMARY KEY (id),
> CONSTRAINT fkey__tbl_favoriten__anlage_id FOREIGN KEY (anlage_id)
> REFERENCES anlagen.tbl_anlage (id) MATCH SIMPLE
> ON UPDATE RESTRICT ON DELETE RESTRICT,
> CONSTRAINT fkey__tbl_favoriten__benutzer_id FOREIGN KEY
> (benutzer_id)
> REFERENCES benutzer.tbl_benutzer (id) MATCH SIMPLE
> ON UPDATE RESTRICT ON DELETE RESTRICT
> ) INHERITS (virtual.tbl_tupelaenderung)
> WITHOUT OIDS;
>
> ALTER TABLE sonstiges.tbl_favoriten OWNER TO usr_dbavt_admin;
> --------------8<----------------------------------------------
> --------------------------
>
> Der neue Besitzer der Tabelle tbl_favoriten hat keine
> Leseberechtigung auf tbl_anlage, was notwendig ist, um den
> Foreign Key Check auszuführen (FK-Checks sind RI-Trigger die
> im Context des Tabellen-Owners ausgeführt werden).

aaaaaaaahhhhhhhhhhhhhhhhhhhhhhhhhhhhhh verdammt!
du bist der held!!! habe dem besitzer seine urspruenglichen rechte
gegeben und siehe da...funzt. :( :)

ich idi dachte mir naemlich, warum sollte der owner was lesen koennen?
ist doch unwichtig! haette nie gedacht das es daran haengt! verdammt,
verdammt, verdammt und wer ist schuld? ich!



> Man kann dies aber nur schwer nachvollziehen, bei mir
> passiert's nur in dieser Reihenfolge (wenn das REVOKE für die
> Rolle test ganz unten steht):
>
> CREATE SCHEMA bernd;
> CREATE TABLE A(id INTEGER NOT NULL PRIMARY KEY); CREATE TABLE
> B(id INTEGER NOT NULL PRIMARY KEY, name TEXT NOT NULL,
> FOREIGN KEY(id) REFERENCES A(id) MATCH SIMPLE ON UPDATE
> RESTRICT ON DELETE RESTRICT);
>
> REVOKE ALL ON a FROM bhe;
> REVOKE ALL ON b FROM bhe;
> GRANT SELECT ON a to bhe;
>
> GRANT SELECT,INSERT,DELETE ON b to bhe;
> ALTER TABLE A OWNER TO test;
>
> INSERT INTO A VALUES (1);
> INSERT INTO A VALUES (2);
> INSERT INTO A VALUES (3);
> INSERT INTO A VALUES (4);
> GRANT USAGE on SCHEMA bernd TO bhe;
>
> GRANT ALL on SCHEMA bernd TO bhe;
> GRANT ALL ON SCHEMA bernd to test;
> REVOKE ALL ON a FROM test;
>
> SET ROLE bhe;
> INSERT INTO bernd.b VALUES (2, '');
>
> ERROR: permission denied for relation a
> CONTEXT: SQL statement "SELECT 1 FROM ONLY "bernd"."a" x
> WHERE "id" =3D $1 FOR SHARE OF x"
>
> Da ich grade zu müde bin, mir das genauer anzusehen,
> verschiebe ich das auf morgen. Es sollte aber nun hoffentlich
> klar sein, wo das Problem liegt.

jupp absolut klar und danke fuer deinen bleistift ;-)


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

--On Freitag, Juni 02, 2006 10:23:19 +0200 rene hankel
<rene.hankel [at] avt-verkehrstechnik.de> wrote:

>> Da ich grade zu müde bin, mir das genauer anzusehen,
>> verschiebe ich das auf morgen. Es sollte aber nun hoffentlich
>> klar sein, wo das Problem liegt.
>
> jupp absolut klar und danke fuer deinen bleistift ;-)

Noch was:

CREATE OR REPLACE RULE oninsert_nodouble AS
ON INSERT TO sonstiges.tbl_favoriten
WHERE 0 < (( SELECT count(tbl_favoriten.id) AS count
FROM sonstiges.tbl_favoriten
WHERE tbl_favoriten.anlage_id =3D new.anlage_id AND
tbl_favoriten.benutzer_id =3D new.benutzer_id)) DO INSTEAD NOTHING;
COMMENT ON RULE oninsert_nodouble ON sonstiges.tbl_favoriten IS 'sorge
dafuer das es keine doppelten eintraege von anlagen und usern in den
favoriten gibt';

Ich verstehe die Intension dieser Rule überhaupt nicht. Wenn du doppelte=

Einträge
der Spalten benutzer_id und anlage_id verhindern willst, nimmst du besser=

einen
UNIQUE INDEX:

CREATE UNIQUE INDEX bla_idx ON foo(col1, col2, ...);

--
Thanks

Bernd

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

http://archives.postgresql.org

>
> CREATE OR REPLACE RULE oninsert_nodouble AS
> ON INSERT TO sonstiges.tbl_favoriten
> WHERE 0 < (( SELECT count(tbl_favoriten.id) AS count
> FROM sonstiges.tbl_favoriten
> WHERE tbl_favoriten.anlage_id =3D new.anlage_id AND
> tbl_favoriten.benutzer_id =3D new.benutzer_id)) DO INSTEAD
> NOTHING; COMMENT ON RULE oninsert_nodouble ON
> sonstiges.tbl_favoriten IS 'sorge dafuer das es keine
> doppelten eintraege von anlagen und usern in den favoriten gibt';
>
> Ich verstehe die Intension dieser Rule überhaupt nicht. Wenn
> du doppelte Einträge der Spalten benutzer_id und anlage_id
> verhindern willst, nimmst du besser einen UNIQUE INDEX:
>
> CREATE UNIQUE INDEX bla_idx ON foo(col1, col2, ...);

schon richtig, aber was passiert wenn ich einen doppelten insert mache? eine

fehlermeldung oder nicht? die muss ich abfangen ect... es ist so wesentlich=

einfacher 4 me, zummal die logik dann in der db liegt und nicht in der
anwendung!
um punkto konsistenz der db moechte ich dies auch der db ueberlassen.

natuerlich ist dein argument stichhaltig, aber ich moechte das so, es sei
denn
es gibt ein echtes manko. aber dies duerfte doch in diesem fall doch nur ein

laufzeitproblem sein?


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

--On Freitag, Juni 02, 2006 11:05:46 +0200 rene hankel
<rene.hankel [at] avt-verkehrstechnik.de> wrote:

> natuerlich ist dein argument stichhaltig, aber ich moechte das so, es sei
> denn
> es gibt ein echtes manko. aber dies duerfte doch in diesem fall doch nur
> ein
>
> laufzeitproblem sein?

Es funktioniert eben nicht, zumindest nicht ohne explizite Sperren.
Wenn eine Transaktion A einfügt und parallel eine Transaktion B denselben=

Wert, dann
"sieht" Transaktion B den Wert von A erst, wenn diese einen COMMIT
durchführt. D.h.
dein COUNT() ist wertlos, weil er in diesem Moment immer 0 liefert.

Wenn du einen unique constraint fehler abfangen willst, arbeite mit
SAVEPOINTS.

--
Thanks

Bernd

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

> Es funktioniert eben nicht, zumindest nicht ohne explizite Sperren.
> Wenn eine Transaktion A einfügt und parallel eine Transaktion
> B denselben Wert, dann "sieht" Transaktion B den Wert von A
> erst, wenn diese einen COMMIT durchführt. D.h.
> dein COUNT() ist wertlos, weil er in diesem Moment immer 0 liefert.
>
> Wenn du einen unique constraint fehler abfangen willst,
> arbeite mit SAVEPOINTS.

mmmmh, logisch deine argumentation ist auf jeden richtig.

soviel ich weis ist jede einzelne anweisung ala 'INSERT INTO ....'
automatische
eine einstufige transaktion. jetzt ist meine frage, wird meine definierte
regel
innerhalb dieser transaktion durchgeführt oder nicht? muesste doch
eigentlich
schon, da die rule direkt die insert-anweisung beeinflussen muss.

ist es besser diese ganze funktionalitaet in eine funktion als transaktion=

zu schreiben oder....?



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

am 06.06.2006, um 17:08:25 +0200 mailte rene hankel folgendes:
> ist es besser diese ganze funktionalitaet in eine funktion als transaktion
> zu schreiben oder....?

Schau Dir das mal an:
http://www.postgresql.org/docs/8.1/interactive/plpgsql-contr ol-structures.html#PLPGSQL-ERROR-TRAPPING


Andreas
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47215, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=== Schollglas Unternehmensgruppe ===

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