On Tue, 7 Jun 2005, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Seems OK to allow them to be visible outside an exception.
> >
> > Pavel just told me off-list that he'd reconsidered and now likes
> > the other way better. So please hold off applying this patch;
> > th
Bruce Momjian writes:
> Seems OK to allow them to be visible outside an exception.
Pavel just told me off-list that he'd reconsidered and now likes
the other way better. So please hold off applying this patch;
there will be another one by and by.
regards, tom lane
-
Patch retracted by author; new one coming.
---
Pavel Stehule wrote:
> Hello
>
> This patch respect last Tom's Lane notes. Is based on first variante,
>
> http://archives.postgresql.org/pgsql-committers/2005-05/msg00303.p
Tom Lane wrote:
> Bruce Momjian writes:
> > Seems OK to allow them to be visible outside an exception.
>
> Pavel just told me off-list that he'd reconsidered and now likes
> the other way better. So please hold off applying this patch;
> there will be another one by and by.
Roger.
--
Bruce
Pavel Stehule wrote:
> Hello
>
> This patch respect last Tom's Lane notes. Is based on first variante,
>
> http://archives.postgresql.org/pgsql-committers/2005-05/msg00303.php
>
> SQLSTATE and SQLERRM are local variables blocks with EXCEPTION clause.
> I wonted respect a litlle bit Oracle beha
Hello
This patch respect last Tom's Lane notes. Is based on first variante,
http://archives.postgresql.org/pgsql-committers/2005-05/msg00303.php
SQLSTATE and SQLERRM are local variables blocks with EXCEPTION clause.
I wonted respect a litlle bit Oracle behavior and therefore exist these
varia
Hello
I have new version. I'll send it early.
Regards
Pavel Stehule
On Sat, 4 Jun 2005, Bruce Momjian wrote:
>
> Your patch has been added to the PostgreSQL unapplied patches list at:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches
>
> It will be applied as soon as one of the Postg
This patch is has been removed from the patch queue for the following
reason:
---
This patch is not ready to be applied -- we're waiting for Pavel to
submit a revised version with the semantics described here:
http://archiv
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list
This patch is not ready to be applied -- we're waiting for Pavel to
submit a revised version with the semantics described here:
http://archives.postgresql.org/pgsql-committers/2005-06/msg00017.php
-Neil
Hello
I changed implementation of SQLSTATE from block scope variables on
function scope variables. I am not sure if it's moust elegant solution,
but is very similar Oracle behavior (there is session scope variable)
CREATE OR REPLACE FUNCTION ff() RETURNS void AS $$
BEGIN
RAISE NOTICE 'No exce
On Tue, 2004-05-11 at 22:56, Neil Conway wrote:
> The only convention I can see is that subclass values not defined by the
> SQL specification begin with 'P'. (This ought to be documented; barring
> any objections, I'll commit a patch stating this in errcodes.h
> explicitly).
I've applied the atta
Neil Conway wrote:
> On Wed, 2004-05-12 at 10:37, Peter Eisentraut wrote:
> > In addition to the conventions that you were already told, classes
> > starting with Y are reserved for PostgreSQL clients.
>
> They are? Under what circumstances would a PostgreSQL client produce
> an error code?
>
> (No
On Wed, 2004-05-12 at 10:37, Peter Eisentraut wrote:
> In addition to the conventions that you were already told, classes starting
> with Y are reserved for PostgreSQL clients.
They are? Under what circumstances would a PostgreSQL client produce an
error code?
(No such error codes exist at the m
On Wed, 2004-05-12 at 00:55, Mahesh Swamy wrote:
> I think that I have missed explaining a point. We are developing a
> proprietary extension to PostgreSQL. This means that some errors that are
> thrown in our extension will never be thrown by the OSS community code.
> Thus, for these cases we shou
Am Mittwoch, 12. Mai 2004 04:07 schrieb Mahesh Swamy:
> 2/ If there is no convention is it ok to use the letter 'x' for all our
> State codes? eg. if we want to add a state under the "53" class, we would
> use "53x001", "53x002" and so on.
That doesn't work, because sqlstate values have to be exac
Thank you Tom and Neil for your replies.
> > 2/ If there is no convention is it ok to use the letter 'x' for all our
> > State codes?
>
> Why would you want to do that?
I think that I have missed explaining a point. We are developing a
proprietary extension to PostgreSQL. This means that some erro
Neil Conway <[EMAIL PROTECTED]> writes:
> On Tue, 2004-05-11 at 22:07, Mahesh Swamy wrote:
>> 1/ Is there a convention for creating sub-class codes.
> The only convention I can see is that subclass values not defined by the
> SQL specification begin with 'P'.
The collection of SQLSTATEs defined b
On Tue, 2004-05-11 at 22:07, Mahesh Swamy wrote:
> 1/ Is there a convention for creating sub-class codes.
The only convention I can see is that subclass values not defined by the
SQL specification begin with 'P'. (This ought to be documented; barring
any objections, I'll commit a patch stating thi
Hi
FAST have developed an extension to the PostgreSQL - replacing the storage
manager with a more enterprise enabled version. This extension throws some
errors that need SQLState codes.
Thus, we would like to ask a couple of question regarding SQLState codes.
1/ Is there a convention for creatin
I've added parsing of the V3 protocol's notice and error messages into its
various fields. This replaces the current error message format of:
SERRORC42P01Mrelation "this_table_doesnt_exist" does not
existFnamespace.cL193RRangeVarGetRelid
with the correct message and allows the programmer to ret
20 matches
Mail list logo
