From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, elein(at)varlena(dot)com, elein <elein(at)sbcglobal(dot)net> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: [SQL] rewriting values with before trigger |
Date: | 2003-04-25 17:20:48 |
Message-ID: | 200304251020.48678.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-sql |
Robert,
> You misunderstood. I don't think it's a bug in postgresql, it's a bug in
the
> application that is hitting against my database. When it doesn't have a
value
> for the timestamp field, it either needs to drop it from the insert statment
> or convert it to null; not send a ''
Incidentally, this sort of problem is why most of my apps are based on "push"
data functions. i.e., instead of the client calling:
INSERT INTO foo VALUES ( id, bar1, bar2, bar3 );
it calls
SELECT df_modify_foo ( id, bar1, bar2, bar3 );
Data-push functions allow me to do a whole array of validation and custom
error message return that would be impractical with triggers. It also
allows me to build security checks in to the back-end, via:
SELECT df_modify_foo ( user_id, session_key, id, bar1, bar2, bar3 )
... allowing me to check all of the following things:
Does the user have a valid session?
Does the user have rights to foo?
Does the user have a lock on foo?
Is this a new foo record, or a modified one?
etc.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | scott.marlowe | 2003-04-25 17:37:21 | Re: Solaris |
Previous Message | Jimmie H. Apsey | 2003-04-25 17:06:32 | Postgres client/server parameters? |
From | Date | Subject | |
---|---|---|---|
Next Message | Dennis Gearon | 2003-04-25 17:47:35 | Re: [SQL] rewriting values with before trigger |
Previous Message | Bruce Momjian | 2003-04-25 16:17:32 | Re: /* */ comments showing up in pg_stat_activity |