David Fetter wrote:
> On Mon, Nov 09, 2009 at 09:01:14PM -0500, Bruce Momjian wrote:
> >
> > I have applied the attached patch to document that FOUND is not affected
> > by EXECUTE, while GET DIAGNOSTICS is.
>
> One minor nit here:
>
> > Index: doc/src/sgml/plpgsql.sgml
> > =
On Mon, Nov 09, 2009 at 09:01:14PM -0500, Bruce Momjian wrote:
>
> I have applied the attached patch to document that FOUND is not affected
> by EXECUTE, while GET DIAGNOSTICS is.
One minor nit here:
> Index: doc/src/sgml/plpgsql.sgml
> ===
I have applied the attached patch to document that FOUND is not affected
by EXECUTE, while GET DIAGNOSTICS is.
---
Robert Haas wrote:
> On Fri, Oct 23, 2009 at 12:05 PM, Pavel Stehule
> wrote:
> > 2009/10/23 Robert Haas :
On Fri, Oct 23, 2009 at 12:05 PM, Pavel Stehule wrote:
> 2009/10/23 Robert Haas :
>> On Fri, Oct 23, 2009 at 10:50 AM, Tom Lane wrote:
>>> Robert Haas writes:
On Fri, Oct 23, 2009 at 9:52 AM, Tom Lane wrote:
> [shrug...] There is also real user demand for not silently breaking
> c
2009/10/23 Robert Haas :
> On Fri, Oct 23, 2009 at 10:50 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Fri, Oct 23, 2009 at 9:52 AM, Tom Lane wrote:
[shrug...] There is also real user demand for not silently breaking
code that works now, which is what we risk anytime we change the
On Fri, Oct 23, 2009 at 10:50 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Oct 23, 2009 at 9:52 AM, Tom Lane wrote:
>>> [shrug...] There is also real user demand for not silently breaking
>>> code that works now, which is what we risk anytime we change the set
>>> of statements that can
On Fri, Oct 23, 2009 at 11:07 AM, Kevin Grittner
wrote:
> Tom Lane wrote:
>
>> Any change here is *not* a bug fix, it is a change of clearly
>> documented and not-obviously-unreasonable behavior. We have to take
>> seriously the likelihood that it will break existing code.
>
> Perhaps plpgsql co
Tom Lane wrote:
> Any change here is *not* a bug fix, it is a change of clearly
> documented and not-obviously-unreasonable behavior. We have to take
> seriously the likelihood that it will break existing code.
Perhaps plpgsql could support tests of SQLSTATE, and recognize '02000'
(the standa
Robert Haas writes:
> On Fri, Oct 23, 2009 at 9:52 AM, Tom Lane wrote:
>> [shrug...] There is also real user demand for not silently breaking
>> code that works now, which is what we risk anytime we change the set
>> of statements that can set FOUND.
> We've had this discussion before and I'm s
Robert Haas wrote:
On Fri, Oct 23, 2009 at 9:52 AM, Tom Lane wrote:
Dimitri Fontaine writes:
I'll go search for more, meantime I'll just add the main goal of this
new thread is to have -hackers know there is a real user demand for
having EXECUTE set FOUND the same way it sets GET DI
On Fri, Oct 23, 2009 at 9:52 AM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> I'll go search for more, meantime I'll just add the main goal of this
>> new thread is to have -hackers know there is a real user demand for
>> having EXECUTE set FOUND the same way it sets GET DIAGNOSTIC.
>
> [shrug..
Dimitri Fontaine writes:
> I'll go search for more, meantime I'll just add the main goal of this
> new thread is to have -hackers know there is a real user demand for
> having EXECUTE set FOUND the same way it sets GET DIAGNOSTIC.
[shrug...] There is also real user demand for not silently breaki
Tom Lane writes:
> Dimitri Fontaine writes:
>> But it will set GET DIAGNOSTIC ... = ROW_COUNT, am I being told on IRC.
>
> This has been discussed before, please read archives.
The thread I found is pretty content free as far as answering my
question goes.
http://archives.postgresql.org/pgsql
Dimitri Fontaine writes:
> But it will set GET DIAGNOSTIC ... = ROW_COUNT, am I being told on IRC.
This has been discussed before, please read archives.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
But it will set GET DIAGNOSTIC ... = ROW_COUNT, am I being told on IRC.
I was really suprised FOUND is not set by EXECUTE in 8.3 when doing a
partitioning UPDATE trigger (we partition a summary table and have to
see about doing UPSERT).
As I wouldn't have figured GET DIAGNOSTIC was the way to go
15 matches
Mail list logo
