Re: Verbosity of Function Return Type Checks

From: Volkan YAZICI <yazicivo(at)ttmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Verbosity of Function Return Type Checks
Date: 2008-09-05 18:25:59
Message-ID: 87iqtabgaw.fsf@alamut.mobiliz.com.tr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 05 Sep 2008, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> I think the best way is to use
>
> subroutine(..., gettext_noop("special error message here"))
>
> at the call sites, and then
>
> errmsg("%s", _(msg))
>
> when throwing the error. gettext_noop() is needed to have the string
> be put into the message catalog, but it doesn't represent any run-time
> effort. The _() macro is what actually makes the translation lookup
> happen. We don't want to incur that cost in the normal no-error case,
> which is why you shouldn't just do _() at the call site and pass an
> already-translated string to the subroutine.

Modified as you suggested. BTW, will there be a similar i18n scenario
for "dropped column" you mentioned below?

>> if (td1->attrs[i]->atttypid &&
>> td2->attrs[i]->atttypid &&
>> td1->attrs[i]->atttypid != td2->attrs[i]->atttypid)
>
>> expression to fix this?
>
> No, that's weakening the compatibility check. (There's a separate issue
> here of teaching plpgsql to actually cope nicely with rowtypes
> containing dropped columns, but that's well beyond the scope of this
> patch.)
>
> What I'm on about is protecting format_type_be() from being passed
> a zero and then failing. Perhaps it would be good enough to do
> something like
>
> OidIsValid(td1->attrs[i]->atttypid) ?
> format_type_with_typemod(td1->attrs[i]->atttypid,
> td1->attrs[i]->atttypmod) :
> "dropped column"
>
> while throwing the error.
>
> BTW, since what's actually being looked at is just the type OID and not
> the typmod, it seems inappropriate to me to show the typmod in the
> error. I'd go with just format_type_be(td1->attrs[i]->atttypid) here
> I think.

Done with format_type_be() usage.

BTW, Alvaro fixed my string concatenations which yielded in lines
exceeding 80 characters width, but I'd want to ask twice if you're sure
with this. Because, IMHO, PostgreSQL is also famous with the quality and
readability of its source code -- that I'm quite proud of as a user,
kudos to developers -- and I think it'd be better to stick with 80
characters width convention as much as one can.

Regards.

Attachment Content-Type Size
plpgsql_validate_tupdesc_compat_wip_4.patch text/x-diff 5.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-09-05 18:30:03 Re: [Review] Tests citext casts by David Wheeler.
Previous Message Tom Raney 2008-09-05 18:21:25 Planner question