Re: Controlling changes in plpgsql variable resolution

Tom Lane wrote:
> Under old-style semantics this will do what the programmer thought.
> Under Oracle semantics it will return the first table row. If
> do-something is security critical then this is enough to call it
> an exploit. The reverse direction (code meant for Oracle behavior
> breaks under old-style) is not difficult to cons up either; I think
> you can find some examples in pgsql-bugs archives from people trying
> to port Oracle code to PG.
>
> Given that people are very prone to intentionally naming things as above
> (for a particularly egregious example try
> http://archives.postgresql.org/pgsql-bugs/2009-10/msg00054.php)
> I think it's entirely foolish to imagine this isn't a real hazard.
> If name collisions were improbable we'd not have so many complaints
> about the current behavior in our archives, and probably wouldn't be
> thinking about changing the behavior at all.

Sorry for the late reply:

Stepping back a bit, is there something we can do to reduce the chances
of variable-name collision? If you are selecting a column called
"first_name", it is logical to put it into a variable called
"first_name", and hence the conflict if that variable is used in a
query.

I know some Oracle people use a 'v_' prefix for variables, but that
always looked ugly to me. Is there something else we could use to
qualify variables used in queries to avoid conflicts?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +