Re: Fix hints on CREATE PROCEDURE errors - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fix hints on CREATE PROCEDURE errors
Date
Msg-id 17024.1533755889@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fix hints on CREATE PROCEDURE errors  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: Fix hints on CREATE PROCEDURE errors
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: REINDEX and shared catalogs
Next
From: Peter Eisentraut
Date:
Subject: Re: memory leak when serializing TRUNCATE in reorderbuffer