Peter Eisentraut <peter_e@gmx.net> writes:
> The field pg_language.lanispl seems to have several different meanings:
> 1. This is a user-defined language.
> 2. This language may be dropped.
> 3. You may define a trigger using a function defined in this language (or
> in C or in internal).
> 4. Functions defined in this language may be called. (see fmgr.c)
> 5. This language needs to be dumped.
> (1) and (2) are now taken care of by the new dependency system. (3)
> seems to aim at disallowing trigger functions in SQL. Perhaps this should
> be made explicit instead of taking this backdoor approach.
Seems unnecessary, since (IIRC) we already have checks that SQL
functions can't return opaque while triggers must do so.
> I don't understand what (4) is intending to do.
fmgr.c uses lanispl to indicate that the function should be called
via the language's handler function, instead of directly.
I suppose we could remove lanispl if we made the convention that a
non-PL language must have InvalidOid in lanplcallfoid; then the
test whether to use a handler is "is lanplcallfoid not zero" rather
than looking at a different column. This does seem cleaner: use
a handler if there is one.
I agree that the other uses of the flag are bogus and need to be
rethought.
> (5) is not really needed if we
> take pg_dump's current approach of associating a language with the
> namespace of the underlying function.
Well, do you like that? It was only a quick hack to get pg_dump
running with schemas; I'm not convinced we really want it to act
that way.
regards, tom lane