Volkan YAZICI wrote:
> On Fri, 05 Sep 2008, Tom Lane <tgl@sss.pgh.pa.us> writes:
> > at the call sites, and then
> >
> > errmsg("%s", _(msg))
> >
> > when throwing the error.
>
> Modified as you suggested. BTW, will there be a similar i18n scenario
> for "dropped column" you mentioned below?
Yes, you need _() around those too.
> Done with format_type_be() usage.
BTW you forgot to remove the quotes around the type names (I know I told
you to add them but Tom gave the reasons why it's not needed) :-)
Those are minor problems that are easily fixed. However there's a
larger issue that Tom mentioned earlier and I concur, which is that the
caller is forming the primary error message and passing it down. It
gets a bit silly if you consider the ways the messages end up worded:
errmsg("returned record type does not match expected record type")); errdetail("Returned type \"%s\" does not match
expectedtype \"%s\" in column \"%s\".", ---> this is the case where it's OK
errmsg("wrong record type supplied in RETURN NEXT")); errdetail("Returned type \"%s\" does not match expected type
\"%s\"in column \"%s\".", --> this is strange
errmsg("returned tuple structure does not match table of trigger event")); errdetail("Returned type \"%s\" does not
matchexpected type \"%s\" in column \"%s\".", --> this is not OK
I've been thinking how to pass down the context information without
feeding the complete string, but I don't find a way without doing
message construction. Construction is to be avoided because it's a pain
for translators.
Maybe we should just use something generic like errmsg("mismatching record type")
and have the caller pass two strings specifying what's the "returned"
tuple and what's the "expected", but I don't see how ... (BTW this is
worth fixing, because every case seems to have appeared independently
without much thought as to other callsites with the same pattern.)
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support