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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
