Обсуждение: What exactly does lanispl mean?

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.  I don't
understand what (4) is intending to do.  (5) is not really needed if we
take pg_dump's current approach of associating a language with the
namespace of the underlying function.

Does anyone have any knowledge about this attribute?  Can it be removed?

-- 
Peter Eisentraut   peter_e@gmx.net

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

Tom Lane writes:

> > (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.

We should probably put the languages into a schema.

-- 
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> 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.

> We should probably put the languages into a schema.

Well, that would be the cleanest answer but it's surely overkill
given the small number of languages (and the fact that superuser
privilege is required to install one).  I don't feel like doing
that much work just to make pg_dump's life a little easier...
        regards, tom lane