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

Re: plpgsql - variable's names conflict with table field

From: Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: plpgsql - variable's names conflict with table field
Date: 2004-02-17 15:47:57
Message-ID: Pine.LNX.4.44.0402171628470.3097-100000@kix.fsv.cvut.cz (view raw or flat)
Thread:
Lists: pgsql-bugs
On Tue, 17 Feb 2004, Tom Lane wrote:

> Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz> writes:
> > 	When I declare variable with same name as field of table, then I 
> > have a problem with insert cmd in plpgsql procedure.
> 
> Don't do that.
> 
> > Is it plpgsql error or my bug?
> 
> You could argue it either way, perhaps, but it's unlikely to get
> changed.  In general plpgsql cannot tell whether a variable name
> appearing in a SQL command ought to be substituted for or not, and so it
> just always does it.  I think trying to be smart would create as many
> pitfalls as it'd solve.  The best practice is not to use plpgsql
> variable names that match table or field names you need to access in the
> same procedure.

I haven't problem with it. I found it when I ported procedures from Solid 
db. Can You add big warning about it to plpgsql documentation? This is 
very tricky "bug". Insert reports syntax error, ok. But Select reports nothink.

Regard
Pavel

> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match
> 


In response to

pgsql-bugs by date

Next:From: Chris CampbellDate: 2004-02-17 17:26:32
Subject: Crash when calling a pl/pgsql function with no row to pass as an argument
Previous:From: Jeff BoesDate: 2004-02-17 15:44:20
Subject: pg_autovacuum bug with temp tables?

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