Joel Burton writes:
> I've lived without having this bite me; I'd think that side-effect functions
> would be unusual in a WHERE clause. I'm just wondering if we should work
> this into the docs somewhere. (Or is it? I took a look, but didn't see
> anything).
I've written up a section about it w
"Joel Burton" <[EMAIL PROTECTED]> writes:
> Is there any generalizable help would could offer to people who write
> functions that have side effects? Don't use them in WHERE (or ON or HAVING)
> clauses? Evaluate the function in a earlier db call, then plug the resolved
> results into the SQL WHERE
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 30, 2002 10:44 AM
> To: Joel Burton
> Cc: Alessio Bragadini; PostgreSQL Hackers
> Subject: Re: [HACKERS] wierd AND condition evaluation for plpgsql
>
>
> "Joel Bu
"Joel Burton" <[EMAIL PROTECTED]> writes:
>>> Actually, at least in some cases, PG does short-circuit logic:
>>> joel@joel=# select false and seeme();
>>> joel@joel=# select true and seeme();
>> If seeme() returns NULL, shouldn't both SELECTs return NULL, and
>> therefore not be short-circuit-abl
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Alessio
> Bragadini
> Sent: Thursday, May 30, 2002 9:04 AM
> To: PostgreSQL Hackers
> Subject: Re: [HACKERS] wierd AND condition evaluation for plpgsql
>
>
> On Tue, 20
On Tue, 2002-05-28 at 16:09, Joel Burton wrote:
> Actually, at least in some cases, PG does short-circuit logic:
> joel@joel=# select false and seeme();
> joel@joel=# select true and seeme();
If seeme() returns NULL, shouldn't both SELECTs return NULL, and
therefore not be short-circuit-able?
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Are these intricacies of SQL standardised anywhere ?
SQL92 section 3.3.4.4, "rule evaluation order" appears to sanction PG's
behavior. In particular note the part that says syntax rules and access
rules are "effectively applied at the same time" (ie, t
On Wed, 2002-05-29 at 02:36, Joel Burton wrote:
> > -Original Message-
> joel@joel=# select true and seeme();
> NOTICE: seeme
> ?column?
> --
> t
> (1 row)
>
>
> It certainly appears to be short circuiting for "select false and seeme()",
> for instance.
>
> It appears that th
On Tue, 2002-05-28 at 21:52, Peter Eisentraut wrote:
> Louis-David Mitterrand writes:
>
> > Shouldn't plpgsql shortcut AND conditions when a previous one fails, as
> > perl does?
>
> Shouldn't perl evaluate all operands unconditionally, like plpgsql does?
>
> Seriously, if you want to change th
Louis-David Mitterrand writes:
> Shouldn't plpgsql shortcut AND conditions when a previous one fails, as
> perl does?
Shouldn't perl evaluate all operands unconditionally, like plpgsql does?
Seriously, if you want to change this you have to complain to the SQL
standards committee.
--
Peter Ei
Louis-David Mitterrand <[EMAIL PROTECTED]> writes:
> 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"
Actually, at least in some cases, PG does short-circuit logic:
create function seeme() returns bool as '
begin
raise notice ''seeme'';
return true;
end'
language plpgsql;
joel@joel=# select false and seeme();
?column?
--
f
(1 row)
joel@joel=# select true and seeme();
NOTIC
12 matches
Mail list logo
