Tom,
> But how would KPSQL know what value the function might have returned?
> Something fishy here ... did you check the postmaster log to see
> whether
> an error is really being reported or not?
Actually, I haven't been able to get the postgresql log
to work since I compiled RC2. I keep mea
Tom,
> This would clearly be a bug, but I cannot replicate the problem:
>
> regression=# SELECT fn_save_order_details (7703, '{34,29,40}','{TRUE,
> TRUE, FALSE}');
> ERROR: referential integrity violation - key referenced
> from order_details not found in orders
> regression=#
Always good to
"Josh Berkus" <[EMAIL PROTECTED]> writes:
> Always good to have you folks test something. This does appear to be a
> bug ... in KPSQL (the KDE GUI for PSQL), not in Postgres. When I run it
> through command-line PSQL, an error is returned; for some reason, KPSQL
> returns the return value for th
Joe,
> I'm not sure if this is what you're looking for, but in 7.1 you can
> do
> something like:
>
> INSERT INTO bar(barpk,foopk) VALUES(barpkval,foopkval);
> GET DIAGNOSTICS rows = ROW_COUNT;
> -- do something based on rows --
There's several other ways I can check, as well. Howe
> However, not all types of errors are so trapped. The most problematic
> un-trapped error is referential integrity: if an INSERT or UPDATE fails
> because of a referential integrity violation, the PL/pgSQL function will
> still see the statement as a success and not error out. Example:
>
I'm
Folks,
I've run up against a problematic limitation of PL/pgSQL's
error-handling ability which could force me to re-write about 25 custom
functions. I'm hoping that you folks can show me a way around the
situation.
THE PROBLEM:
PL/pgSQL handles errors though "Implied Transactions", whe
