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@candle.pha.pa.us | (610) 35
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
> solutio
Pavel Stehule wrote:
> On Tue, 19 Apr 2005, Tom Lane wrote:
>
> > Bruce Momjian 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-incom
Tom Lane wrote:
> Bruce Momjian 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
Dinesh Pandey wrote:
> 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.
Well, right now it is in:
http://momjian.postgresq
On Tue, 19 Apr 2005, Tom Lane wrote:
> Bruce Momjian 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
>
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.
>
>
Bruce Momjian 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.
reg
EMAIL PROTECTED] On Behalf Of Bruce Momjian
Sent: Tuesday, April 19, 2005 9:29 AM
To: Pavel Stehule
Cc: Tom Lane; [EMAIL PROTECTED]; pgsql-patches@postgresql.org
Subject: Re: [PATCHES] [HACKERS] Implementation of SQLCODE and SQLERRM
variables
Guys, is this patch ready for application? I think so, but a
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 simil
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.
Neil Conway <[EMAIL PROTECTED]> 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.
- 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);
+
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_blo
>
> 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
Pavel Stehule <[EMAIL PROTECTED]> 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
16 matches
Mail list logo
