Re: What exactly does lanispl mean?

Peter Eisentraut <peter_e(at)gmx(dot)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