Thank you Tom.
> I think the most likely implementation would involve adding hooks
> in the parser at places where "unknown column" errors are about to
> be thrown, so that a function language could check for a match to
> one of its variable names only after the query-exposed names are
Would this be the right path to follow?
Assuming we are allowed to include parameter names into ParseState, we can
match the "non existing" colnames against the list of parameter
names when transformColumnRef (or someware safe in that path). I Think this
we at least can parse a function when CreateFunction is called.
If the above is correct to implement then the check should have low
precedence in order to not break
the current functionality (first colnames, then $n params and then parameter
In response to
pgsql-hackers by date
|Next:||From: Peter Eisentraut||Date: 2007-10-30 23:05:42|
|Subject: Re: [COMMITTERS] pgsql: simple script to pull together a very small (<500k) tar file|
|Previous:||From: Pavel Stehule||Date: 2007-10-30 22:08:00|
|Subject: Re: problem with pgAdmin beta2 on w2k3|