Обсуждение: plpgsql extension install nitpick

Поиск
Список
Период
Сортировка

plpgsql extension install nitpick

От
Josh Kupershmidt
Дата:
Hi all,

I noticed that the plpgsql extension gets installed with an extension
comment of 'PL/pgSQL procedural language', which comes from
plpgsql.control. That seems fine and dandy, but take a look at the
following query (modified from psql's \dL query):

SELECT l.lanname AS "Name",      pg_catalog.pg_get_userbyid(l.lanowner) as "Owner",      l.lanpltrusted AS "Trusted",
  d.description
 
FROM pg_catalog.pg_language l
LEFT JOIN pg_description d
ON d.classoid = l.tableoid AND d.objoid = l.oid;

You should see plpgsql has no comment. The comment does show up if
you're looking for extension comments, like in this query (lifted from
the pg_comments patch):

SELECTd.objoid, d.classoid, d.objsubid,'extension'::text AS objtype,ext.extnamespace AS objnamespace,ext.extname AS
objname,d.description,nsp.nspnameIN ('pg_catalog', 'information_schema') AS is_system
 
FROMpg_description dJOIN pg_extension ext ON d.classoid = ext.tableoid AND d.objoid = ext.oidJOIN pg_namespace nsp ON
ext.extnamespace= nsp.oid
 
WHEREd.objsubid = 0;

So, basically, I would like to have that comment show up for the first
query. I imagine this could be fixed quite easily by adding:
 COMMENT ON PROCEDURAL LANGUAGE plpgsql IS 'PL/pgSQL procedural language';

somewhere like plpgsql--1.0.sql. And if you're wondering why I care
about any of this, it's because I'd like to fix up psql's \dL command
to display the comments attached to procedural languages, and I'd
rather not have to special-case plpgsql.

Josh


Re: plpgsql extension install nitpick

От
Tom Lane
Дата:
Josh Kupershmidt <schmiddy@gmail.com> writes:
> [ plpgsql's comment is now attached to the extension, not the PL itself ]

> So, basically, I would like to have that comment show up for the first
> query. I imagine this could be fixed quite easily by adding:
>   COMMENT ON PROCEDURAL LANGUAGE plpgsql IS 'PL/pgSQL procedural language';

I can't get excited about adding duplicative comments at different
semantic levels.

We just went through an exercise to suppress comments on functions that
are meant to be accessed through operators, and this seems like much the
same kind of situation.  I think it will not be long before COMMENT ON
PROCEDURAL LANGUAGE is a historical curiosity, because everybody will
ship their PLs as extensions and the comment on the extension will be
the thing to look at.  IOW, the fact that there even is a database
object type "procedural language" will soon be an implementation detail
of interest only to PL authors.

Or, perhaps more concretely: if we do as you suggest, won't \dd be
putting out two identical comments on two different kinds of objects,
and won't people find that confusing and inconvenient?

> ... And if you're wondering why I care
> about any of this, it's because I'd like to fix up psql's \dL command
> to display the comments attached to procedural languages, and I'd
> rather not have to special-case plpgsql.

Well, all four PLs supplied with core work the same way here, so a
special case targeted at only plpgsql would be quite wrong anyway.
        regards, tom lane


Re: plpgsql extension install nitpick

От
Josh Kupershmidt
Дата:
On Sat, Jul 2, 2011 at 11:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Josh Kupershmidt <schmiddy@gmail.com> writes:
>> [ plpgsql's comment is now attached to the extension, not the PL itself ]
>
>> So, basically, I would like to have that comment show up for the first
>> query. I imagine this could be fixed quite easily by adding:
>>   COMMENT ON PROCEDURAL LANGUAGE plpgsql IS 'PL/pgSQL procedural language';
>
> I can't get excited about adding duplicative comments at different
> semantic levels.

I admit I don't like the idea of duplicating comments either :-(
Though maybe the extension comment could be tweaked to 'Extension
supplying PL/pgSQL procedural language', or something like that.

> We just went through an exercise to suppress comments on functions that
> are meant to be accessed through operators, and this seems like much the
> same kind of situation.  I think it will not be long before COMMENT ON
> PROCEDURAL LANGUAGE is a historical curiosity, because everybody will
> ship their PLs as extensions and the comment on the extension will be
> the thing to look at.  IOW, the fact that there even is a database
> object type "procedural language" will soon be an implementation detail
> of interest only to PL authors.
>
> Or, perhaps more concretely: if we do as you suggest, won't \dd be
> putting out two identical comments on two different kinds of objects,
> and won't people find that confusing and inconvenient?

Well, currently I believe \dd shows comments for neither languages nor
extensions. And IMO it doesn't need to, either: these should properly
be handled by \dx and \dL, respectively.

(The proposed pg_comments view would show 'plpgsql' twice, once as
objtype = language, and once as objtype = extension -- I agree that's
not ideal).

>> ... And if you're wondering why I care
>> about any of this, it's because I'd like to fix up psql's \dL command
>> to display the comments attached to procedural languages, and I'd
>> rather not have to special-case plpgsql.
>
> Well, all four PLs supplied with core work the same way here, so a
> special case targeted at only plpgsql would be quite wrong anyway.

Not sure I follow you here... the COMMENT for plpgsql is in a
different place than for 'c', 'internal', and 'sql', which is what I'm
on about.

Anyways, if you're not keen on adding in another comment for plpgsql,
do you have a suggestion on how to make \dL display the comments for
all languages?

Josh


Re: plpgsql extension install nitpick

От
Peter Eisentraut
Дата:
On lör, 2011-07-02 at 23:22 -0400, Tom Lane wrote:
> We just went through an exercise to suppress comments on functions
> that are meant to be accessed through operators, and this seems like
> much the same kind of situation.  I think it will not be long before
> COMMENT ON PROCEDURAL LANGUAGE is a historical curiosity, because
> everybody will ship their PLs as extensions and the comment on the
> extension will be the thing to look at.  IOW, the fact that there even
> is a database object type "procedural language" will soon be an
> implementation detail of interest only to PL authors.

Well, you still write functions in the language and refer to it in the
SQL commands, so it is reasonable to know about the language as opposed
to the extension it is in.  You wouldn't remove man pages just because
an RPM package description exists.




Re: plpgsql extension install nitpick

От
Tom Lane
Дата:
Peter Eisentraut <peter_e@gmx.net> writes:
> On lör, 2011-07-02 at 23:22 -0400, Tom Lane wrote:
>> [ don't want to put duplicate comments on PLs and their extensions ]

> Well, you still write functions in the language and refer to it in the
> SQL commands, so it is reasonable to know about the language as opposed
> to the extension it is in.  You wouldn't remove man pages just because
> an RPM package description exists.

Well, if I'm in the minority I'll yield gracefully.  Anybody else have
an opinion?
        regards, tom lane


Re: plpgsql extension install nitpick

От
Tom Lane
Дата:
Josh Kupershmidt <schmiddy@gmail.com> writes:
> On Sat, Jul 2, 2011 at 11:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Josh Kupershmidt <schmiddy@gmail.com> writes:
>>> [ plpgsql's comment is now attached to the extension, not the PL itself ]
>>> ... And if you're wondering why I care
>>> about any of this, it's because I'd like to fix up psql's \dL command
>>> to display the comments attached to procedural languages, and I'd
>>> rather not have to special-case plpgsql.

>> Well, all four PLs supplied with core work the same way here, so a
>> special case targeted at only plpgsql would be quite wrong anyway.

> Not sure I follow you here... the COMMENT for plpgsql is in a
> different place than for 'c', 'internal', and 'sql', which is what I'm
> on about.

I was referring to plperl, plpython, pltcl.  If we change this then all
four of those extensions should be changed the same way,  The other
languages you mention are not extensions.
        regards, tom lane


Re: plpgsql extension install nitpick

От
Robert Haas
Дата:
On Sun, Jul 3, 2011 at 12:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> On lör, 2011-07-02 at 23:22 -0400, Tom Lane wrote:
>>> [ don't want to put duplicate comments on PLs and their extensions ]
>
>> Well, you still write functions in the language and refer to it in the
>> SQL commands, so it is reasonable to know about the language as opposed
>> to the extension it is in.  You wouldn't remove man pages just because
>> an RPM package description exists.
>
> Well, if I'm in the minority I'll yield gracefully.  Anybody else have
> an opinion?

I don't see any harm in commenting it in both places.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


Re: plpgsql extension install nitpick

От
Tom Lane
Дата:
Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Jul 3, 2011 at 12:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Well, if I'm in the minority I'll yield gracefully. �Anybody else have
>> an opinion?

> I don't see any harm in commenting it in both places.

OK, done.

I did not add comment commands to the "upgrade" scripts.  We could do
that, but there's a risk of overwriting a previously user-supplied
comment, so on the whole I think it's better not to.
        regards, tom lane