Skip site navigation (1) Skip section navigation (2)

Re: wierd AND condition evaluation for plpgsql

From: "Joel Burton" <joel(at)joelburton(dot)com>
To: "Louis-David Mitterrand" <vindex(at)apartia(dot)org>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: wierd AND condition evaluation for plpgsql
Date: 2002-05-28 13:09:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Actually, at least in some cases, PG does short-circuit logic:

create function seeme() returns bool as '
    raise notice ''seeme'';
    return true;
language plpgsql;

joel(at)joel=# select false and seeme();
(1 row)

joel(at)joel=# select true and seeme();
NOTICE:  seeme
(1 row)

In your case, the problem is short-circuiting a test, it's that the full
statement must be parsed and prepared, and it's probably in this stage that
the illegal use of old. in an insert jumps up.


Joel BURTON | joel(at)joelburton(dot)com | | aim: wjoelburton
Knowledge Management & Technology Consultant

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org]On Behalf Of Louis-David
> Mitterrand
> Sent: Tuesday, May 28, 2002 3:21 AM
> To: pgsql-hackers(at)postgresql(dot)org
> Subject: [HACKERS] wierd AND condition evaluation for plpgsql
> Hi,
> I just noticed plpgsql evaluates all AND'ed conditions even if the first
> one fails. Example:
> 	elsif TG_OP = ''UPDATE'' and old.type_reponse = ''abandon''
> This will break stuff if the trigger is used on INSERT as
> "old.type_reponse" will be substituted and return an error.
> Shouldn't plpgsql shortcut AND conditions when a previous one fails, as
> perl does?
> --
>     OENONE: Quoi ?
>     PHEDRE: Je te l'ai prédit, mais tu n'as pas voulu.
>                                           (Phèdre, J-B Racine,
> acte 3, scène 3)
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2002-05-28 13:33:07
Subject: Re: strange update problem with 7.2.1
Previous:From: Valentine ZaretskyDate: 2002-05-28 12:48:52
Subject: Re: SRF rescan testing

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group