Lists: | pgsql-hackerspgsql-patches |
---|
From: | Ali Baba <idofyear(at)yahoo(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Exception ERROR Code |
Date: | 2005-03-05 14:03:20 |
Message-ID: | 20050305140321.76214.qmail@web52501.mail.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Hi ,
I am looking for the way to get the error code
corresponding to the exception in plpgsql.
Can any body guide me.
Thanks,
Asif Ali
__________________________________
Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web
http://birthday.yahoo.com/netrospective/
From: | Michael Fuhr <mike(at)fuhr(dot)org> |
---|---|
To: | Ali Baba <idofyear(at)yahoo(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Exception ERROR Code |
Date: | 2005-03-05 15:31:47 |
Message-ID: | 20050305153147.GA72148@winnie.fuhr.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
On Sat, Mar 05, 2005 at 06:03:20AM -0800, Ali Baba wrote:
> I am looking for the way to get the error code
> corresponding to the exception in plpgsql.
What exception? Can you describe what you're trying to do? Are
you using the EXCEPTION clause that's available in the latest
release, or are you hacking PL/pgSQL itself?
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
From: | Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz> |
---|---|
To: | Ali Baba <idofyear(at)yahoo(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Exception ERROR Code |
Date: | 2005-03-05 19:06:23 |
Message-ID: | Pine.LNX.4.44.0503052002430.15509-100000@kix.fsv.cvut.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Hello,
It's no possible now. But I prepared small patch which implemented
variables sqlcode and sqlerrm for plpgsql. I can send it tomorrow.
regards
Pavel Stehule
On Sat, 5 Mar 2005, Ali Baba wrote:
> Hi ,
>
> I am looking for the way to get the error code
> corresponding to the exception in plpgsql.
> Can any body guide me.
>
> Thanks,
> Asif Ali
>
>
>
>
> __________________________________
> Celebrate Yahoo!'s 10th Birthday!
> Yahoo! Netrospective: 100 Moments of the Web
> http://birthday.yahoo.com/netrospective/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>
From: | Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz> |
---|---|
To: | Ali Baba <idofyear(at)yahoo(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, <pgsql-patches(at)postgresql(dot)org> |
Subject: | Implementation of SQLCODE and SQLERRM variables for PL/pgSQL |
Date: | 2005-03-06 19:24:38 |
Message-ID: | Pine.LNX.4.44.0503062003220.32436-600000@kix.fsv.cvut.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Hello
This is my second patch, than please will be tolerant :-). For one my
project I miss information about exception when I use EXCEPTION WITH
OTHERS THEN. I found two Oracle's varaibles SQLCODE and SQLERRM which
carry this information. With patch you can:
--
-- Test of built variables SQLERRM and SQLCODE
--
create or replace function trap_exceptions() returns void as $_$
begin
begin
raise exception 'first exception';
exception when others then
raise notice '% %', SQLCODE, SQLERRM;
end;
raise notice '% %', SQLCODE, SQLERRM;
begin
raise exception 'last exception';
exception when others then
raise notice '% %', SQLCODE, SQLERRM;
end;
return;
end; $_$ language plpgsql;
select trap_exceptions();
drop function trap_exceptions();
CREATE FUNCTION
NOTICE: P0001 first exception
NOTICE: 000000 Sucessful completion
NOTICE: P0001 last exception
trap_exceptions
-----------------
(1 row)
DROP FUNCTION
Regards,
Pavel Stehule
Attachment | Content-Type | Size |
---|---|---|
test.sql | text/plain | 538 bytes |
test.out | text/plain | 187 bytes |
plpgsql.h.diff | text/plain | 66 bytes |
pl_exec.c.diff | text/plain | 1.0 KB |
gram.y.diff | text/plain | 1.3 KB |
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz> |
Cc: | Ali Baba <idofyear(at)yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Implementation of SQLCODE and SQLERRM variables for PL/pgSQL |
Date: | 2005-03-06 20:05:05 |
Message-ID: | 6324.1110139505@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz> writes:
> This is my second patch, than please will be tolerant :-). For one my
> project I miss information about exception when I use EXCEPTION WITH
> OTHERS THEN. I found two Oracle's varaibles SQLCODE and SQLERRM which
> carry this information.
I think we discussed this last year and decided that it would be a bad
idea to use those names because Oracle's use of them is not exactly
compatible with our error codes and messages. SQLCODE in particular is
not compatible at all --- it's an integer in Oracle, isn't it?
IIRC we had put off solving this problem until we decided what to do
with RAISE. There really needs to be some changes in RAISE to allow it
to raise a specific error code rather than always P0001, but exactly
what is still undecided.
Some other problems with your patch: no documentation, and not in
diff -c format. Plain diff patches are never acceptable because
it's too risky to apply them against files that might have changed
since you started working with them. Also, it's much easier to
deal with one patch than with a separate diff for each file.
(diff -c -r between an original and a modified directory is one
good way to produce a useful patch.)
regards, tom lane
From: | Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Ali Baba <idofyear(at)yahoo(dot)com>, <pgsql-hackers(at)postgresql(dot)org>, <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Implementation of SQLCODE and SQLERRM variables for |
Date: | 2005-03-06 20:51:49 |
Message-ID: | Pine.LNX.4.44.0503062133440.32436-100000@kix.fsv.cvut.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
>
> I think we discussed this last year and decided that it would be a bad
> idea to use those names because Oracle's use of them is not exactly
> compatible with our error codes and messages. SQLCODE in particular is
> not compatible at all --- it's an integer in Oracle, isn't it?
There is more incompatibilities to Oracle. SQLERRM is function on Oracle,
only if you use it without parametr, returns current message error.
SQLCODE is really integer. But it's only names. There is no problem change
it.
>
> IIRC we had put off solving this problem until we decided what to do
> with RAISE. There really needs to be some changes in RAISE to allow it
> to raise a specific error code rather than always P0001, but exactly
> what is still undecided.
I didn't know it. But for my work is SQLERRM more important. I have more
constraints on tables and I need detect which which constraints raise
exception. The possibility EXCEPTION WITH OTHERS is nice, but not too much
usefull because I have not possibility get some informations about except.
>
> Some other problems with your patch: no documentation, and not in
> diff -c format. Plain diff patches are never acceptable because
> it's too risky to apply them against files that might have changed
> since you started working with them. Also, it's much easier to
> deal with one patch than with a separate diff for each file.
> (diff -c -r between an original and a modified directory is one
> good way to produce a useful patch.)
>
I am not sure, I able create documentation - my english is poor. I will
change diff's format and send patch again.
Thank you
Pavel
From: | Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Implementation of SQLCODE and SQLERRM variables for |
Date: | 2005-03-07 09:28:57 |
Message-ID: | Pine.LNX.4.44.0503071015110.4380-400000@kix.fsv.cvut.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Hello,
I used different format now. Documentation:
This patch is implementation of variables SQLERRM and SQLCODE for plpgsql
language. Variable SQLCODE contains five chars PostgreSQL Error Code,
SQLERRM contains relevant message last catched exception. All variables
are attached to plpgsql_block and have local scope. Default values are
'00000' for SQLCODE and 'Sucessful completion' for SQLERRM. Some example
of using is in file test.sql.
Regards
Pavel Stehule
Attachment | Content-Type | Size |
---|---|---|
test.sql | text/plain | 538 bytes |
test.out | text/plain | 187 bytes |
sqlcode.diff | text/plain | 4.7 KB |
From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Implementation of SQLCODE and SQLERRM variables |
Date: | 2005-03-07 22:21:34 |
Message-ID: | 422CD3EE.9060202@samurai.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
- You should write some regression tests for this functionality
- You should update the documentation
- Is there a reason why you've made the type of SQLCODE `text', rather
than integer?
Pavel Stehule wrote:
> + fict_vars_sect :
> + {
> + plpgsql_ns_setlocal(false);
> + PLpgSQL_variable *var;
> + var = plpgsql_build_variable(strdup("sqlcode"), 0,
> + plpgsql_build_datatype(TEXTOID, -1), true);
> + $$.sqlcode_varno = var->dno;
> + var = plpgsql_build_variable(strdup("sqlerrm"), 0,
> + plpgsql_build_datatype(TEXTOID, -1), true);
This shouldn't be strdup'ing its first argument (and even if it needed
to make a copy, it should use pstrdup). Also, my personal preference
would be to implement this without creating a new production (i.e. just
include it inline in the body of the pl_block production).
> *** src.old/pl_exec.c 2005-02-24 02:11:40.000000000 +0100
> --- src/pl_exec.c 2005-03-07 09:53:52.630243888 +0100
> ***************
> *** 809,814 ****
> --- 809,828 ----
> int i;
> int n;
>
> + /* setup SQLCODE and SQLERRM */
> + PLpgSQL_var *var;
> +
> + var = (PLpgSQL_var *) (estate->datums[block->sqlcode_varno]);
> + var->isnull = false;
> + var->freeval = false;
> + var->value = DirectFunctionCall1(textin, CStringGetDatum("00000"));
> +
> + var = (PLpgSQL_var *) (estate->datums[block->sqlerrm_varno]);
> + var->isnull = false;
> + var->freeval = false;
> + var->value = DirectFunctionCall1(textin, CStringGetDatum("Sucessful completion"));
`freeval' should be true, no? (Not sure it actually matters, but text is
certainly not pass-by-value).
> ***************
> *** 918,923 ****
> --- 932,957 ----
[...]
> + var = (PLpgSQL_var *) (estate->datums[block->sqlcode_varno]);
> + var->value = DirectFunctionCall1(textin, CStringGetDatum(tbuf));
> +
> + var = (PLpgSQL_var *) (estate->datums[block->sqlerrm_varno]);
> + var->value = DirectFunctionCall1(textin, CStringGetDatum(edata->message));
You should probably pfree() the old values before replacing them.
-Neil
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Implementation of SQLCODE and SQLERRM variables for |
Date: | 2005-03-07 22:31:16 |
Message-ID: | 14780.1110234676@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Neil Conway <neilc(at)samurai(dot)com> writes:
> - Is there a reason why you've made the type of SQLCODE `text', rather
> than integer?
The value isn't an integer ... which gets back to my point that this is
not compatible with Oracle's idea of SQLCODE and therefore we should *not*
use that name for it.
BTW: the patch has some memory-leak problems, I believe, because it is
studiously not following the var->freeval protocol. Now that I look,
it appears to be copied-and-pasted from some existing code that also
gets this wrong :-(
regards, tom lane
From: | Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <neilc(at)samurai(dot)com> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Implementation of SQLCODE and SQLERRM variables for |
Date: | 2005-03-08 09:18:36 |
Message-ID: | Pine.LNX.4.44.0503081003370.13222-400000@kix.fsv.cvut.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Hello,
I changed code by your and Neil's notes. The name SQLCODE isn't well,
better is SQLSTATE. It's very similar DB2 variable. I am not sure, so my
solutions is best. Propably not. It's only particular solution for
plpgsql. The files plpgsql.sql and plpgsql.out are diffs for regression
tests.
This patch is implementation of variables SQLERRM and SQLSTATE for plpgsql
language. Variable SQLSTATE contains five chars PostgreSQL Error Code,
SQLERRM contains relevant message last catched exception. All variables
are attached to plpgsql_block and have local scope. Default values are
'00000' for SQLSTATE and 'Sucessful completion' for SQLERRM.
Regards
Pavel Stehule
Attachment | Content-Type | Size |
---|---|---|
plpgsql.sql | text/plain | 955 bytes |
plpgsql.out | text/plain | 577 bytes |
sqlstate.diff | text/plain | 5.4 KB |
From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, neilc(at)samurai(dot)com, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Implementation of SQLCODE and SQLERRM variables |
Date: | 2005-04-19 03:59:13 |
Message-ID: | 200504190359.j3J3xDP02838@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Guys, is this patch ready for application? I think so, but am not 100%
sure.
---------------------------------------------------------------------------
Pavel Stehule wrote:
> Hello,
>
> I changed code by your and Neil's notes. The name SQLCODE isn't well,
> better is SQLSTATE. It's very similar DB2 variable. I am not sure, so my
> solutions is best. Propably not. It's only particular solution for
> plpgsql. The files plpgsql.sql and plpgsql.out are diffs for regression
> tests.
>
> This patch is implementation of variables SQLERRM and SQLSTATE for plpgsql
> language. Variable SQLSTATE contains five chars PostgreSQL Error Code,
> SQLERRM contains relevant message last catched exception. All variables
> are attached to plpgsql_block and have local scope. Default values are
> '00000' for SQLSTATE and 'Sucessful completion' for SQLERRM.
>
> Regards
>
> Pavel Stehule
>
Content-Description:
[ Attachment, skipping... ]
Content-Description:
[ Attachment, skipping... ]
Content-Description:
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From: | "Dinesh Pandey" <dpandey(at)secf(dot)com> |
---|---|
To: | "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "'Pavel Stehule'" <stehule(at)kix(dot)fsv(dot)cvut(dot)cz> |
Cc: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <neilc(at)samurai(dot)com>, <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Implementation of SQLCODE and SQLERRM variables |
Date: | 2005-04-19 04:04:41 |
Message-ID: | 20050419040739.3617A52A4B@svr1.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Hello All,
Where can I find patch for SQLERRM/SQLSTATE variable implementation?.
I am using Postgres 8.0.1.
Its very urgent.... because I have an assignment of Porting Oracle's PL?SQL
into PL/pgSQL.
Thanks
Dinesh Pandey
-----Original Message-----
From: pgsql-patches-owner(at)postgresql(dot)org
[mailto:pgsql-patches-owner(at)postgresql(dot)org] On Behalf Of Bruce Momjian
Sent: Tuesday, April 19, 2005 9:29 AM
To: Pavel Stehule
Cc: Tom Lane; neilc(at)samurai(dot)com; pgsql-patches(at)postgresql(dot)org
Subject: Re: [PATCHES] [HACKERS] Implementation of SQLCODE and SQLERRM
variables
Guys, is this patch ready for application? I think so, but am not 100%
sure.
---------------------------------------------------------------------------
Pavel Stehule wrote:
> Hello,
>
> I changed code by your and Neil's notes. The name SQLCODE isn't well,
> better is SQLSTATE. It's very similar DB2 variable. I am not sure, so my
> solutions is best. Propably not. It's only particular solution for
> plpgsql. The files plpgsql.sql and plpgsql.out are diffs for regression
> tests.
>
> This patch is implementation of variables SQLERRM and SQLSTATE for
plpgsql
> language. Variable SQLSTATE contains five chars PostgreSQL Error Code,
> SQLERRM contains relevant message last catched exception. All variables
> are attached to plpgsql_block and have local scope. Default values are
> '00000' for SQLSTATE and 'Sucessful completion' for SQLERRM.
>
> Regards
>
> Pavel Stehule
>
Content-Description:
[ Attachment, skipping... ]
Content-Description:
[ Attachment, skipping... ]
Content-Description:
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz>, neilc(at)samurai(dot)com, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Implementation of SQLCODE and SQLERRM variables for |
Date: | 2005-04-19 04:46:06 |
Message-ID: | 16521.1113885966@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Guys, is this patch ready for application? I think so, but am not 100%
> sure.
I haven't read the code yet, but in any case I still object to choosing
Oracle-like names for Oracle-incompatible functionality. We need to
settle on better names.
regards, tom lane
From: | Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <neilc(at)samurai(dot)com>, <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Implementation of SQLCODE and SQLERRM |
Date: | 2005-04-19 05:00:20 |
Message-ID: | Pine.LNX.4.44.0504190656200.32148-100000@kix.fsv.cvut.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Hello,
I am not sure, I corrected memory problems, I think, but there are some
changes in plpgsql code. I'l update patch today.
Regards
Pavel Stehule
On Mon, 18 Apr 2005, Bruce Momjian wrote:
>
> Guys, is this patch ready for application? I think so, but am not 100%
> sure.
>
> ---------------------------------------------------------------------------
>
> Pavel Stehule wrote:
> > Hello,
> >
> > I changed code by your and Neil's notes. The name SQLCODE isn't well,
> > better is SQLSTATE. It's very similar DB2 variable. I am not sure, so my
> > solutions is best. Propably not. It's only particular solution for
> > plpgsql. The files plpgsql.sql and plpgsql.out are diffs for regression
> > tests.
> >
> > This patch is implementation of variables SQLERRM and SQLSTATE for plpgsql
> > language. Variable SQLSTATE contains five chars PostgreSQL Error Code,
> > SQLERRM contains relevant message last catched exception. All variables
> > are attached to plpgsql_block and have local scope. Default values are
> > '00000' for SQLSTATE and 'Sucessful completion' for SQLERRM.
> >
> > Regards
> >
> > Pavel Stehule
> >
>
> Content-Description:
>
> [ Attachment, skipping... ]
>
> Content-Description:
>
> [ Attachment, skipping... ]
>
> Content-Description:
>
> [ Attachment, skipping... ]
>
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster
>
>
From: | Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, <neilc(at)samurai(dot)com>, <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Implementation of SQLCODE and SQLERRM |
Date: | 2005-04-19 06:09:24 |
Message-ID: | Pine.LNX.4.44.0504190748050.32594-100000@kix.fsv.cvut.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
On Tue, 19 Apr 2005, Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Guys, is this patch ready for application? I think so, but am not 100%
> > sure.
>
> I haven't read the code yet, but in any case I still object to choosing
> Oracle-like names for Oracle-incompatible functionality. We need to
> settle on better names.
>
I changed names on SQLSTATE and SQLERRM. The behave our SQLSTATE and db2
SQLSTATE is very similar. But Oracle support SQLSTATE too (in ANSI mode).
Only Oracle support SQLERRM.
http://developer.mimer.com/howto/howto_25.htm
SQLSTATE, a 5-character return value specified by the SQL standard,
replaced SQLCODE years ago (SQL-92?). Perhaps both Oracle and DB2/2
have support for it.
But I didn't find good informations about error trapping in ANSI SQL. All
informations are about Oracle or DB2 :-(.
Best Regards
Pavel Stehule
From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, neilc(at)samurai(dot)com, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Implementation of SQLCODE and SQLERRM variables |
Date: | 2005-04-19 14:34:54 |
Message-ID: | 200504191434.j3JEYsN03957@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Pavel Stehule wrote:
> Hello,
>
> I am not sure, I corrected memory problems, I think, but there are some
> changes in plpgsql code. I'l update patch today.
OK, great thanks.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz>, neilc(at)samurai(dot)com, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Implementation of SQLCODE and SQLERRM variables |
Date: | 2005-04-19 14:35:49 |
Message-ID: | 200504191435.j3JEZnL04114@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Guys, is this patch ready for application? I think so, but am not 100%
> > sure.
>
> I haven't read the code yet, but in any case I still object to choosing
> Oracle-like names for Oracle-incompatible functionality. We need to
> settle on better names.
OK, are the values returned not the same as the Oracle values? If they
aren't, you are right, we need another name.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, neilc(at)samurai(dot)com, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Implementation of SQLCODE and SQLERRM variables |
Date: | 2005-04-19 14:37:00 |
Message-ID: | 200504191437.j3JEb0G04431@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Pavel Stehule wrote:
> On Tue, 19 Apr 2005, Tom Lane wrote:
>
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > Guys, is this patch ready for application? I think so, but am not 100%
> > > sure.
> >
> > I haven't read the code yet, but in any case I still object to choosing
> > Oracle-like names for Oracle-incompatible functionality. We need to
> > settle on better names.
> >
>
> I changed names on SQLSTATE and SQLERRM. The behave our SQLSTATE and db2
> SQLSTATE is very similar. But Oracle support SQLSTATE too (in ANSI mode).
> Only Oracle support SQLERRM.
>
> http://developer.mimer.com/howto/howto_25.htm
>
> SQLSTATE, a 5-character return value specified by the SQL standard,
> replaced SQLCODE years ago (SQL-92?). Perhaps both Oracle and DB2/2
> have support for it.
>
> But I didn't find good informations about error trapping in ANSI SQL. All
> informations are about Oracle or DB2 :-(.
Oh, it sounds like we are OK then with the names you used.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, neilc(at)samurai(dot)com, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Implementation of SQLCODE and SQLERRM variables |
Date: | 2005-04-19 14:38:43 |
Message-ID: | 200504191438.j3JEchW04791@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers pgsql-patches |
Removed. New version coming.
---------------------------------------------------------------------------
Pavel Stehule wrote:
> Hello,
>
> I changed code by your and Neil's notes. The name SQLCODE isn't well,
> better is SQLSTATE. It's very similar DB2 variable. I am not sure, so my
> solutions is best. Propably not. It's only particular solution for
> plpgsql. The files plpgsql.sql and plpgsql.out are diffs for regression
> tests.
>
> This patch is implementation of variables SQLERRM and SQLSTATE for plpgsql
> language. Variable SQLSTATE contains five chars PostgreSQL Error Code,
> SQLERRM contains relevant message last catched exception. All variables
> are attached to plpgsql_block and have local scope. Default values are
> '00000' for SQLSTATE and 'Sucessful completion' for SQLERRM.
>
> Regards
>
> Pavel Stehule
>
Content-Description:
[ Attachment, skipping... ]
Content-Description:
[ Attachment, skipping... ]
Content-Description:
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073