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

From Darren Duncan
Subject Re: resolving SQL ambiguity (was Re: WIP: Allow SQL-lang funcs to ref params by param name)
Date
Msg-id 4D8E54CE.1060006@darrenduncan.net
Whole thread Raw
In response to Re: resolving SQL ambiguity (was Re: WIP: Allow SQL-lang funcs to ref params by param name)  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: resolving SQL ambiguity (was Re: WIP: Allow SQL-lang funcs to ref params by param name)
Next
From: Dimitri Fontaine
Date:
Subject: Re: WIP: Allow SQL-language functions to reference parameters by parameter name