On Thu, Apr 14, 2011 at 11:37 AM, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> rhaas=# CREATE OR REPLACE FUNCTION developer_lookup(id integer) >> RETURNS text AS $$SELECT name FROM developer WHERE id = $1$$ LANGUAGE >> sql STABLE; >> >> Now, when this person attempts to recreate this function on a >> hypothetical version of PostgreSQL that thinks "id" is ambiguous, it >> doesn't work. > > Unless we make it so that no such version ever exists. Meaning that the > code works fine as is or using WHERE id = developer_lookup.id. AS id > can't ever be the parameter in this case, you're just fine. > > Bearing in mind that $1 etc shortcuts still are available, I don't > really see this qualification of parameter names with function names so > big a problem that we should find a way to avoid it and risk breaking > compatibility. > > Don't forget that any ambiguity here will mean *huge* migration costs.
If I'm reading your email correctly, we're in agreement. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
