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.
> 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 Campbell||Date: 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 Boes||Date: 2004-02-17 15:44:20|
|Subject: pg_autovacuum bug with temp tables?|