Re: Deprecation

Greg Stark <gsstark(at)mit(dot)edu> writes:
> On Fri, Oct 16, 2009 at 10:23 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> (I would actually not mind getting rid of it, because that would greatly
>> simplify a problem I'm wrestling with right now, namely how to put hooks
>> into the parser for resolution of plpgsql variables. But we need to be
>> honest about what it's going to do to users.)

> I was actually expecting you to come down on the side of "keep it
> until it gets in the way". But if it's getting in the way already then
> it seems reasonable to start talking about getting rid of it.

Yeah. The problem is that I'd like to have plpgsql install a hook that
runs at the end of transformColumnRef and has an opportunity to provide
a reference to a plpgsql var if nothing was found in the normal SQL
lookups. 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. While that
can probably be unwound somehow, it's going to be a major PITA, and
there would be no way to hide the fact that a lock got taken on x before
we changed our minds about including it in the query. Considering that
this is all legacy behavior anyway it would be nice to not have to fix
it.

So, while I do think it's something we should leave alone until it gets
in the way, this is a sufficiently large value of "in the way" that I'm
willing to talk about removing add_missing_from. I'm just concerned
about the impact of that, considering that an app that still depends on
it came up as recently as yesterday.

regards, tom lane