Re: Open 7.1 items - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Open 7.1 items
Date
Msg-id 200102161715.MAA18002@candle.pha.pa.us
Whole thread Raw
In response to Re: Open 7.1 items  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Open 7.1 items  (Philip Warner <pjw@rhyme.com.au>)
List pgsql-hackers
Can someone comment on this?  Seems GET DIAGNOSTICS is wrong from
Peter's reading of SQL92, and mine too.


> Bruce Momjian writes:
> 
> > > Bruce Momjian writes:
> > >
> > > > New PL/pgSQL GET DIAGNOSTICS statement for SPI value access (Jan)
> > >
> > > If someone can show me an example of how it operates I can write up
> > > something.
> >
> > I found:
> >
> >   > Quoting a recent message by Jan Wieck <janwieck@Yahoo.com>:
> >   > :Do a
> >   > :
> >   > :    GET DIAGNOSTICS SELECT PROCESSED INTO <int4_variable>;
> >   > :
> >   > :directly  after  an  INSERT,  UPDATE  or DELETE statement and you'll know
> >   > :how many rows have been hit.
> >   > :
> >   > :Also you can get the OID of an inserted row with
> >   > :
> >   > :    GET DIAGNOSTICS SELECT RESULT INTO <int4_variable>;
> >   >
> >
> > Looking at plpgsql/src/gram.y, it only supports PROCESSED (rows
> > returned/affected) and RESULT (OID).  The grammar indicates that only
> > SELECT is allowed in GET DIAGNOSTICS SELECT.  Jan says it works for
> > INSERT/UPDATE/DELETE too, but I guess you still use GET DIAGNOSTICS
> > SELECT.
> 
> May I suggest that this is the wrong syntax?  It should be
> 
> GET DIAGNOSTICS <variable> = ROW_COUNT;
> 
> See SQL99 part 2, clause 19.1.
> 
> -- 
> Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/
> 
> 


--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: floating point representation
Next
From: Adam Haberlach
Date:
Subject: Something smells in this schema...