Re: resolving SQL ambiguity (was Re: WIP: Allow SQL-lang funcs to ref params by param name)

Pavel Stehule wrote:
> sorry - I dislike this. The design is correct, but it is against to
> SQL verbosity. A reader must to thinking about missing tablenames. I
> dont't think so it is good solution, because it doesn't solve a
> backing compatibility problem - somebody must to fix a function still,
> and I think so it is much preferable to fix like:
> 
>   select (mytbl.mycol + myvar * myparam) as mynewcol from mytbl;
> 
> your proposal saves a five chars, but it has a negative impacts on
> readability - there should be more tables.
> 
> There are no reason to introduce a new concepts - SQL knows a aliases.

Well, going forward, I know I would much rather have to say "mytbl.mycol" than 
have to say "myfunc.myparam".  And I certainly would want to expect that when 
one says "... as foo" that this "foo" is treated as a declaration unambiguously 
and is never substituted for some parameter or there be other grief as I seem to 
recall having in 8.4. -- Darren Duncan