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 |
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 |