Pavel Stehule <pavel.steh...@gmail.com> writes:
> 2012/3/9 Peter Eisentraut <pete...@gmx.net>:
>> What would be the qualifications for being an internal or an external
>> checker? Why couldn't your plpgsql checker be an external checker?
> plpgsql checker cannot be external checker, because it reuse 70% of
> plpgsql environment, - parser, runtime, ...
Well, that just means that it'd be a good idea for that function to be
supplied by the same shared library that supplies the plpgsql execution
functions. There wouldn't need to be any connection that the core
system particularly understands. So, like Peter, I'm not quite sure
what distinction is meant to be drawn by "internal" vs "external".
The thing that really struck me about Peter's previous comments was the
desire to support multiple checkers per PL. I had been assuming that
we'd just extend the "validator" model in some way --- either another
column in pg_language or extending the API for validator functions.
Neither of those work if we want to allow multiple checkers. Now,
I'm not at all convinced that multiple checkers are worth the trouble
... but if they are it seems like we need a different system catalog to
store them in. And the entries in that catalog wouldn't necessarily be
created by the same extension that creates the PL language.
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
