Skip site navigation (1) Skip section navigation (2)

Re: ALTER command reworks

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, PgHacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ALTER command reworks
Date: 2013-01-07 21:14:32
Message-ID: CADyhKSWMP6coCo2pcLQJ09wTus6LBqyYRNthCmkUL_QpvnULWQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
2013/1/7 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Jan 7, 2013 at 3:43 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>>> I checked this patch.  It needed a rebase for the changes to return
>>> OIDs.  Attached patch applies to current HEAD.  In general this looks
>>> good, with one exception: it's using getObjectDescriptionOids() to build
>>> the messages to complain in case the object already exists in the
>>> current schema, which results in diffs like this:
>>>
>>> -ERROR:  event trigger "regress_event_trigger2" already exists
>>> +ERROR:  event trigger regress_event_trigger2 already exists
>>>
>>> I don't know how tense we are about keeping the quotes, but I fear there
>>> would be complaints because it took us lots of sweat, blood and tears to
>>> get where we are now.
>>>
>>> If this is considered a problem, I think the way to fix it is to have a
>>> getObjectDescriptionOids() variant that quotes the object name in the
>>> output.
>
>> This sort of thing has been rejected repeatedly in the past on
>> translation grounds:
>
> Yes.  I'm surprised Alvaro isn't well aware of the rules against trying
> to build error messages out of sentence fragments: see first item under
> http://www.postgresql.org/docs/devel/static/nls-programmer.html#NLS-GUIDELINES
>
> Presence or absence of quotes is the very least of this code's i18n
> problems.
>
> If we had no other choice, we might consider a workaround such as that
> suggested in "Assembling Error Messages"
> http://www.postgresql.org/docs/devel/static/error-style-guide.html#AEN98605
> but frankly I'm not convinced that this patch is attractive enough to
> justify a degradation in message readability.
>
Sorry, I forgot Robert pointed out same thing before.
I'll reconstruct the portion to raise an error message.

Thanks,
-- 
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>


In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2013-01-07 21:16:38
Subject: Re: psql \l to accept patterns
Previous:From: Robert HaasDate: 2013-01-07 21:07:51
Subject: Re: Improve compression speeds in pg_lzcompress.c

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group