2009/5/25 Pavel Stehule <pavel.steh...@gmail.com>: > 2009/5/24 Tom Lane <t...@sss.pgh.pa.us>: >> Pavel Stehule <pavel.steh...@gmail.com> writes: >>> ==Steps== >>> 1. add hook to analyser (transform stage) to substitute unknown >>> columnref by param - when analyser detect unknown columnref, then call >>> callback, that returns possible para node or NULL (when external >>> environment doesn't have a variable). Returned param should be typed >>> or unknown (for polymorphic params). >> >> IMHO the hook definition should support both the case of external >> variables taking precedence over query variables and vice versa. >> I don't think the core parser should be forcing that decision. In any >> case we'd probably need both options for plpgsql, so as to be able to >> support both traditional and Oracle-compatible behavior. > > good idea >
the problem is place for hook variable - it should be in ParseState because we need call hooked functions from environments that install hook. Pavel >> >> I'd be inclined to do that by letting the hook function interpose >> itself between the parser and the regular transformColumnRef processing, >> so that it can call the regular transformColumnRef processing either >> before or after doing its external lookups. Giving it control only >> after the regular processing fails would mean there's no way to let >> external variables take precedence. >> > > ok > >>> 2. add special modes to sql parser: >> >> None of those seem like a good idea to me. The only part that seems >> useful is warning about conflicts between external variables and query >> variables. That can be implemented by the hook function itself, if we >> define the hook behavior as above. >> > > there is minimal one necessary - for polymorphic variables, we know > name, but we don't know type. And without types, we can't to transform > correctly functions. > > regards > Pavel Stehule > > >> regards, tom lane >> > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers