Thread: Fix hints on CREATE PROCEDURE errors
When testing out CREATE PROCEDURE with 11 beta 2, I noticed, the hints
in the errors reference DROP FUNCTION, which doesn't work for
procedures. DROP ROUTINE works for both functions and procedures, so
this patch should work for both.
Please CC me when responding as I don't currently subscribe to the
list.
Thanks,
Jeremy
From 1e4880e77b2b11917021e9d46756264013bd87d5 Mon Sep 17 00:00:00 2001
From: Jeremy Evans <code@jeremyevans.net>
Date: Mon, 6 Aug 2018 11:01:00 -0700
Subject: [PATCH] Have hint use DROP ROUTINE instead of DROP FUNCTION
The current code's hint is misleading for procedures:
CREATE OR REPLACE PROCEDURE a(in int)
LANGUAGE SQL
AS $$
SELECT NULL;
$$;
# CREATE PROCEDURE
CREATE OR REPLACE PROCEDURE a(inout int)
LANGUAGE SQL
AS $$
SELECT NULL;
$$;
# ERROR: cannot change return type of existing function
# HINT: Use DROP FUNCTION a(integer) first.
DROP FUNCTION a(integer);
# ERROR: a(integer) is not a function
DROP ROUTINE a(integer);
# DROP ROUTINE
DROP ROUTINE should work for both functions and procedures.
---
src/backend/catalog/pg_proc.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/backend/catalog/pg_proc.c b/src/backend/catalog/pg_proc.c
index 9b4015d0d4..84ee8d686d 100644
--- a/src/backend/catalog/pg_proc.c
+++ b/src/backend/catalog/pg_proc.c
@@ -409,7 +409,7 @@ ProcedureCreate(const char *procedureName,
ereport(ERROR,
(errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
errmsg("cannot change return type of existing function"),
- errhint("Use DROP FUNCTION %s first.",
+ errhint("Use DROP ROUTINE %s first.",
format_procedure(HeapTupleGetOid(oldtup)))));
/*
@@ -434,7 +434,7 @@ ProcedureCreate(const char *procedureName,
(errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
errmsg("cannot change return type of existing function"),
errdetail("Row type defined by OUT parameters is different."),
- errhint("Use DROP FUNCTION %s first.",
+ errhint("Use DROP ROUTINE %s first.",
format_procedure(HeapTupleGetOid(oldtup)))));
}
@@ -477,7 +477,7 @@ ProcedureCreate(const char *procedureName,
(errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
errmsg("cannot change name of input parameter \"%s\"",
old_arg_names[j]),
- errhint("Use DROP FUNCTION %s first.",
+ errhint("Use DROP ROUTINE %s first.",
format_procedure(HeapTupleGetOid(oldtup)))));
}
}
@@ -501,7 +501,7 @@ ProcedureCreate(const char *procedureName,
ereport(ERROR,
(errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
errmsg("cannot remove parameter defaults from existing function"),
- errhint("Use DROP FUNCTION %s first.",
+ errhint("Use DROP ROUTINE %s first.",
format_procedure(HeapTupleGetOid(oldtup)))));
proargdefaults = SysCacheGetAttr(PROCNAMEARGSNSP, oldtup,
@@ -527,7 +527,7 @@ ProcedureCreate(const char *procedureName,
ereport(ERROR,
(errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
errmsg("cannot change data type of existing parameter default value"),
- errhint("Use DROP FUNCTION %s first.",
+ errhint("Use DROP ROUTINE %s first.",
format_procedure(HeapTupleGetOid(oldtup)))));
newlc = lnext(newlc);
}
--
2.17.1
Hi. On 2018/08/07 3:32, Jeremy Evans wrote: > When testing out CREATE PROCEDURE with 11 beta 2, I noticed, the hints > in the errors reference DROP FUNCTION, which doesn't work for > procedures. Good catch. > DROP ROUTINE works for both functions and procedures, so > this patch should work for both. Not sure if we should fix it the way your patch does, but it seems you forgot to include changes to the expected output of some of the regression tests affected by this patch. Attached updated patch includes those. Thanks, Amit
Attachment
On 06/08/2018 20:32, Jeremy Evans wrote: > The current code's hint is misleading for procedures: > > CREATE OR REPLACE PROCEDURE a(in int) > LANGUAGE SQL > AS $$ > SELECT NULL; > $$; > # CREATE PROCEDURE > > CREATE OR REPLACE PROCEDURE a(inout int) > LANGUAGE SQL > AS $$ > SELECT NULL; > $$; > # ERROR: cannot change return type of existing function > # HINT: Use DROP FUNCTION a(integer) first. Yes, the hint should be changed. But I also think the error message should be changed to be more appropriate to the procedure situation (where is the return type?). Attached patch does both. Unlike your patch, I kept the "DROP FUNCTION" message for the function case. It might be too confusing otherwise. Thoughts? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> Yes, the hint should be changed. But I also think the error message
> should be changed to be more appropriate to the procedure situation
> (where is the return type?). Attached patch does both. Unlike your
> patch, I kept the "DROP FUNCTION" message for the function case. It
> might be too confusing otherwise. Thoughts?
I'm not a translator, but if I were, stuff like "Use DROP %s %s first."
would probably confuse me. IMO it's too close to assembling a message
out of parts, even if it's true that neither %s needs translation.
I think you'd be better off with
isprocedure ? errhint("Use DROP PROCEDURE %s first.", ...)
: errhint("Use DROP FUNCTION %s first.", ...)
Or if that seems too carpal-tunnel-inducing, maybe a workable compromise
is
dropcmd = (prokind == PROKIND_PROCEDURE ? "DROP PROCEDURE" : "DROP FUNCTION");
/* translator: first %s is DROP FUNCTION or DROP PROCEDURE */
errhint("Use %s %s first.", dropcmd, ...)
Looks reasonable other than that quibble.
regards, tom lane
> On Aug 8, 2018, at 3:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> Yes, the hint should be changed. But I also think the error message
>> should be changed to be more appropriate to the procedure situation
>> (where is the return type?). Attached patch does both. Unlike your
>> patch, I kept the "DROP FUNCTION" message for the function case. It
>> might be too confusing otherwise. Thoughts?
>
> I'm not a translator, but if I were, stuff like "Use DROP %s %s first."
> would probably confuse me. IMO it's too close to assembling a message
> out of parts, even if it's true that neither %s needs translation.
> I think you'd be better off with
>
> isprocedure ? errhint("Use DROP PROCEDURE %s first.", ...)
> : errhint("Use DROP FUNCTION %s first.", ...)
>
> Or if that seems too carpal-tunnel-inducing, maybe a workable compromise
> is
>
> dropcmd = (prokind == PROKIND_PROCEDURE ? "DROP PROCEDURE" : "DROP FUNCTION");
>
> /* translator: first %s is DROP FUNCTION or DROP PROCEDURE */
> errhint("Use %s %s first.", dropcmd, ...)
>
> Looks reasonable other than that quibble.
To help move this along, I went ahead and applied Tom’s first suggestion
to the patch. I tested the various scenarios and it seemed to work.
Jonathan
Attachment
This has been committed. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
> On Aug 18, 2018, at 4:22 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > > This has been committed. Thanks - I’ve moved it off of the open items list. Jonathan