Warning for missing createlang

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I have written a patch to issue an hint if someone tries to create a
function in a language that isn't loaded into the database:

ERROR: language "plpgsql" does not exist
HINT: Perhaps you need to use 'createlang' to load the language into
the database.

I know Peter didn't like this idea in the past, but we are getting too
many people who forget createlang, and with our new HINT tags, it seems
appropriate.

I still agree with Peter's opinion ... this hint is fairly silly,
especially since it would pop out for simple misspellings of language
names.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I have written a patch to issue an hint if someone tries to create a
function in a language that isn't loaded into the database:

ERROR: language "plpgsql" does not exist
HINT: Perhaps you need to use 'createlang' to load the language into
the database.

I know Peter didn't like this idea in the past, but we are getting too
many people who forget createlang, and with our new HINT tags, it seems
appropriate.

I still agree with Peter's opinion ... this hint is fairly silly,
especially since it would pop out for simple misspellings of language
names.

What can we do to help people remember they have forgotten to load the
language? The post that question here too often. I don't see any
problem with a hint that starts with "Perhaps".

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

I have written a patch to issue an hint if someone tries to create a
function in a language that isn't loaded into the database:

test=> CREATE FUNCTION xx() RETURNS INT AS '
test'> select 1'
test-> LANGUAGE 'plpgsql';
ERROR: language "plpgsql" does not exist
HINT: Perhaps you need to use 'createlang' to load the language into
the database.

I know Peter didn't like this idea in the past, but we are getting too
many people who forget createlang, and with our new HINT tags, it seems
appropriate.

OK, Peter and Tom don't like it. :-(

How about this, that also suggests you mistyped the name:

HINT: Perhaps you need to use 'createlang' to load the language into
the database, or you mistyped the language name.

                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

Bruce Momjian wrote:

I have written a patch to issue an hint if someone tries to create a
function in a language that isn't loaded into the database:

test=> CREATE FUNCTION xx() RETURNS INT AS '
test'> select 1'
test-> LANGUAGE 'plpgsql';
ERROR: language "plpgsql" does not exist
HINT: Perhaps you need to use 'createlang' to load the language into
the database.

I know Peter didn't like this idea in the past, but we are getting too
many people who forget createlang, and with our new HINT tags, it seems
appropriate.

OK, Peter and Tom don't like it. :-(

How about this, that also suggests you mistyped the name:

HINT: Perhaps you need to use 'createlang' to load the language into
the database, or you mistyped the language name.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Why not list out the languages we *do* know about, and tell them it's
not in the list? Or is that too much work?

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Bruce Momjian wrote:

HINT: Perhaps you need to use 'createlang' to load the language into
the database, or you mistyped the language name.

Why not list out the languages we *do* know about, and tell them it's
not in the list? Or is that too much work?

Seems like it would clutter the error message without really addressing
Bruce's concern. I doubt that seeing the list of available languages
would do much to jog a newbie's memory about needing to run createlang.

We could answer my objection about the hint popping out on misspelled
language names if the code were to arrange to put out the hint only when
the language name is one of "plpgsql", "pltcl", "pltclu", etc. This
would have to use a hard-coded list of loadable language names, since
by definition looking in pg_language won't help. It would be enough of
a maintenance PITA that I don't especially want to do it ... but it
would ensure that the hint is likely to be relevant.

regards, tom lane

On Fri, 2003-09-05 at 09:52, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Bruce Momjian wrote:

HINT: Perhaps you need to use 'createlang' to load the language into
the database, or you mistyped the language name.

Why not list out the languages we *do* know about, and tell them it's
not in the list? Or is that too much work?

Seems like it would clutter the error message without really addressing
Bruce's concern. I doubt that seeing the list of available languages
would do much to jog a newbie's memory about needing to run createlang.

Ok, it's a hint right? Step 1 is to merge the fuzzystrmatch contrib
module into main line code. Step 2 is to use that code to determine a
close match.

CREATE FUNCTION .... LANGUAGE 'plgsql';

System notices the error, and looks for languages in pg_language that
have similar names to 'plgsql', finds 'plpgsql'.

ERROR: Language 'plgsql' not found
HINT: Perhaps you intended to use the language 'plpgsql?

Lots of work (both to implement and maintain) but it would be a neat
trick.

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Bruce Momjian wrote:

HINT: Perhaps you need to use 'createlang' to load the language into
the database, or you mistyped the language name.

Why not list out the languages we *do* know about, and tell them it's
not in the list? Or is that too much work?

Seems like it would clutter the error message without really addressing
Bruce's concern. I doubt that seeing the list of available languages
would do much to jog a newbie's memory about needing to run createlang.

We could answer my objection about the hint popping out on misspelled
language names if the code were to arrange to put out the hint only when
the language name is one of "plpgsql", "pltcl", "pltclu", etc. This
would have to use a hard-coded list of loadable language names, since
by definition looking in pg_language won't help. It would be enough of
a maintenance PITA that I don't especially want to do it ... but it
would ensure that the hint is likely to be relevant.

OK, new output is:

test=> create function xx() returns int as '
test'> select 1'
test-> language 'plpgsql';
ERROR: language "plpgsql" does not exist
HINT: You need to use 'createlang' to load the language into the database.
test=> create function xx() returns int as '
test'> select 1'
test-> language 'XXplpgsql';
ERROR: language "xxplpgsql" does not exist

Patch attached.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

We could answer my objection about the hint popping out on misspelled
language names if the code were to arrange to put out the hint only when
the language name is one of "plpgsql", "pltcl", "pltclu", etc. This
would have to use a hard-coded list of loadable language names, since
by definition looking in pg_language won't help. It would be enough of
a maintenance PITA that I don't especially want to do it ... but it
would ensure that the hint is likely to be relevant.

OK, new output is:

You forgot pltclu, and I believe plpython is now called plpythonu, and
I'm not sure whether there's a plperlu, and if you're going to include
outside-the-distro languages then I am pretty sure there's a plruby.
See what I mean about the maintenance headache this will cause?

BTW, duplicating the ereport is no fun. I'd suggest the coding style
used in some other places, with errhint called in a conditional
expression:

ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
errmsg("language \"%s\" does not exist", languageName),
known_language(languageName) ?
errhint("You need to use 'createlang' to load the language into the database.") : 0));

where known_language() is a little subroutine that has the strcmp()s.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

We could answer my objection about the hint popping out on misspelled
language names if the code were to arrange to put out the hint only when
the language name is one of "plpgsql", "pltcl", "pltclu", etc. This
would have to use a hard-coded list of loadable language names, since
by definition looking in pg_language won't help. It would be enough of
a maintenance PITA that I don't especially want to do it ... but it
would ensure that the hint is likely to be relevant.

OK, new output is:

You forgot pltclu, and I believe plpython is now called plpythonu, and
I'm not sure whether there's a plperlu, and if you're going to include
outside-the-distro languages then I am pretty sure there's a plruby.
See what I mean about the maintenance headache this will cause?

I don't mind the maintenance. I just want people to stop getting stuck
creating plpsql functions. Frankly, I don't care if we only test for
plpgsql (the most common case). It doesn't have to be perfect --- it
only prints a HINT. I willing to put some imperfect code in there to
improve usability.

BTW, duplicating the ereport is no fun. I'd suggest the coding style
used in some other places, with errhint called in a conditional
expression:

ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
errmsg("language \"%s\" does not exist", languageName),
known_language(languageName) ?
errhint("You need to use 'createlang' to load the language into the database.") : 0));

where known_language() is a little subroutine that has the strcmp()s.

Here is the new output:

test=> create function xx() returns int as '
test'> select 1'
test-> language 'XXplpgsql';
ERROR: language "xxplpgsql" does not exist
test=> create function xx() returns int as '
test'> select 1'
test-> language 'plpgsql';
ERROR: language "plpgsql" does not exist
HINT: You need to use 'createlang' to load the language into the
database.

Why does the ': 0' work? I didn't figure that would work, but it does.

Patch attached.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

BTW, duplicating the ereport is no fun. I'd suggest the coding style
used in some other places, with errhint called in a conditional
expression:

Why does the ': 0' work? I didn't figure that would work, but it does.

The return values of the errxxx() subfunctions don't matter (they all
just return zero anyway). What they do is stuff their arguments into
a behind-the-scenes data structure that ereport will use when control
finally gets to it. ereport is declared as taking a "..." argument
list, but it makes no attempt to actually look at what was passed as
its arguments. So we don't really care what happens when the
?-expression test fails, as long as errhint() doesn't execute. A
constant zero is about the minimum thing we can put in the else-part
to keep the compiler happy.

regards, tom lane

Bruce Momjian writes:

How about this, that also suggests you mistyped the name:

HINT: Perhaps you need to use 'createlang' to load the language into
the database, or you mistyped the language name.

That's only one step away from this:

peter=# SELECT * FROM test;
ERROR: relation "test" does not exist
HINT: Perhaps you need to use "CREATE TABLE" to create the table in the
database, or you mistyped the table name.

I think not...

--
Peter Eisentraut peter_e@gmx.net

Bruce Momjian writes:

I don't mind the maintenance. I just want people to stop getting stuck
creating plpsql functions.

Then put plpgsql in the default installation.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut wrote:

Bruce Momjian writes:

I don't mind the maintenance. I just want people to stop getting stuck
creating plpsql functions.

Then put plpgsql in the default installation.

Fine with me. I thought others didn't want it.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Peter Eisentraut wrote:

Bruce Momjian writes:

How about this, that also suggests you mistyped the name:

HINT: Perhaps you need to use 'createlang' to load the language into
the database, or you mistyped the language name.

That's only one step away from this:

peter=# SELECT * FROM test;
ERROR: relation "test" does not exist
HINT: Perhaps you need to use "CREATE TABLE" to create the table in the
database, or you mistyped the table name.

I think not...

I never suggested that. Just because the extreme is wrong doesn't make
the case we are discussing wrong.

If the hint is useful, then we add it. I don't see the above as useful,
while I see the CREATE FUCTION as useful. No one is posting asking why
they have to create the table before selecting from it.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Peter Eisentraut wrote:

Bruce Momjian writes:

I don't mind the maintenance. I just want people to stop getting stuck
creating plpsql functions.

Then put plpgsql in the default installation.

Fine with me. I thought others didn't want it.

There are good security arguments not to have it in the default install,
no? I certainly don't think that avoiding having grotty coding for a
hint is an argument that trumps our past reasons not to do it.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Peter Eisentraut wrote:

Bruce Momjian writes:

I don't mind the maintenance. I just want people to stop getting stuck
creating plpsql functions.

Then put plpgsql in the default installation.

Fine with me. I thought others didn't want it.

There are good security arguments not to have it in the default install,
no? I certainly don't think that avoiding having grotty coding for a
hint is an argument that trumps our past reasons not to do it.

Yes, of course they are independent arguments. Jan isn't comfortable
with it being included, and I think that is what has kept it out.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

--On Friday, September 05, 2003 22:37:09 +0200 Peter Eisentraut
<peter_e@gmx.net> wrote:

Bruce Momjian writes:

I don't mind the maintenance. I just want people to stop getting stuck
creating plpsql functions.

Then put plpgsql in the default installation.

Why don't we do that now? It would seem to me to be a good thing(tm) to
have
it in.

LER

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Tom Lane writes:

There are good security arguments not to have it in the default install,
no?

I think last time the only reason we saw was that dump restoring would be
difficult. I don't see any security reasons.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut wrote:

Tom Lane writes:

There are good security arguments not to have it in the default install,
no?

I think last time the only reason we saw was that dump restoring would be
difficult. I don't see any security reasons.

That could be overcome by doing a 'drop language' before running your
restore, couldn't it? Maybe it would also be useful for such cases to
have a switches on initdb and pg_dump to inhibit creation of the language.

I did see a reference in the archives to a problem with heavy recursion
as a possible security hole. I guess my answer to that would be that if
you are worried about it you should drop the language, but I don't see
this alone as a reason not to install it by default. After all, you
don't need plpgsql to bring the system to its knees :-)

But maybe there's some other reason my search didn't find.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

I did see a reference in the archives to a problem with heavy recursion
as a possible security hole. I guess my answer to that would be that if
you are worried about it you should drop the language, but I don't see
this alone as a reason not to install it by default. After all, you
don't need plpgsql to bring the system to its knees :-)

Yeah, now that we allow recursion in SQL functions, you don't need a PL
language to overflow the stack. So that particular argument is seeming
a bit weak. Were there any other security arguments against making
plpgsql standard?

Inability to load existing pg_dump archives might be a bigger objection.
However, we could fix that if pg_restore were modified to not stop dead
in its tracks upon encountering an error. IMHO that was a wrong choice
from the beginning ... pg_dump scripts don't act that way, and
pg_restore should not either.

regards, tom lane

Andrew Dunstan kirjutas L, 06.09.2003 kell 16:14:

Peter Eisentraut wrote:

Tom Lane writes:

There are good security arguments not to have it in the default install,
no?

I think last time the only reason we saw was that dump restoring would be
difficult. I don't see any security reasons.

That could be overcome by doing a 'drop language' before running your
restore, couldn't it?

or to have CREATE OR REPLACE LANGUAGE (like we have for FUNCTIONS).

-------------------
Hannu