Peter Eisentraut wrote:
> On m?n, 2011-01-17 at 07:37 +0100, Magnus Hagander wrote:
> > >> which, as Magnus points out, includes non-procedural languages (SQL).
> > >>
> > >> I think that "list languages" could be confusing to newcomers -- the
> > >> very people who might be reading through the help output of psql for
> > >> the first time -- who might suppose that "languages" has something to
> > >> do with the character sets supported by PostgreSQL, and might not even
> > >> be aware that a variety of procedural languages can be used inside the
> > >> database.
> > >
> > > Fair point.
> >
> > Yeah. Procedural langauges may strictly be wrong, but people aren't
> > likely to misunderstand it.
>
> The term "procedural" in this context originated with Oracle's PL/SQL,
> which is a procedural language extension to the non-procedural SQL
> language. From this came PostgreSQL's PL/pgSQL, and that naming was
> then continued with PL/Tcl, at which point "PL/$X" lost its original
> meaning of "procedural extension to the non-procedural language $X" and
> meant more or less "handler for writing PostgreSQL functions in language
> $X".
>
> Otherwise PL/Scheme will blow your mind. :)
>
> Think of "procedural language" as "language for writing [PostgreSQL]
> procedures". As was pointed out, it's also a useful convention for
> distinguishing this from other "languages", such as message
> translations.
FYI, I always refer to them as server-side language, to distinguish them
from client-side languages.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
