Re: What exactly does lanispl mean?

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