Tom Lane wrote: > Greg Stark <gsst...@mit.edu> writes: > > On Fri, Oct 16, 2009 at 12:26 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> However, if the columnref looks like "x.y" where x happens to > >> match some table in the database (and not in the query) that doesn't > >> have a column y, the implicit-RTE code will have already modified the > >> querytree before finding out that column y doesn't exist. > > > Hm, so if you do nothing then really the only thing that doesn't work > > is if you have add_missing_from then plpgsql record variables wouldn't > > work when you tried to reference their columns? > > "Do nothing" isn't the right phrase here --- it would take a great deal > of work and ugly, hard-to-maintain code to get it to work even that badly. > The code paths in transformColumnRef are fairly messy already :-(. > Getting rid of add_missing_from would definitely make it easier to > refactor to support hooks for external variable sources. > > The approach I had been thinking about proposing, before David piped up > with his modest proposal, was to have external variables take precedence > over implicit RTEs --- ie, we'd call the hook *before* trying the > add_missing_from case. But that seems pretty weird, and it'd still be > messy to program. What it would mainly accomplish is to avoid the extra > lock hazard.
Sounds like a good reason to remove add_missing_from in 8.5. -- 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
