Re: Explicit relation name in VACUUM VERBOSE log

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Explicit relation name in VACUUM VERBOSE log
Date: 2017-10-02 07:33:52
Message-ID: 43C78FC2-C52B-4B37-8447-3973EA1031E8@yesql.se
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

> On 29 Aug 2017, at 17:21, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Tue, Aug 22, 2017 at 2:23 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> Yes, we can. I'm not sure why you would do this only for VACUUM
>> though? I see many messages in various places that need same treatment
>
> I'm skeptical about the idea of doing this too generally.
>
> rhaas=> select * from foo;
> ERROR: permission denied for relation foo
>
> Do we really want to start saying public.foo in all such error
> messages? To me, that's occasionally helpful but more often just
> useless chatter.
>
> One problem with making this behavior optional is that we'd then need
> two separate translatable strings in every case, one saying "table %s
> has problems" and the other saying "table %s.%s has problems". Maybe
> we could avoid that via some clever trick, but that's how we're doing
> it in some existing cases.
>
> I have a feeling we're making a small patch with a narrow goal into a
> giant patch for which everyone has a different goal.

Based on the concerns raised in this thread which are left to address or
resolve, and the fact that the patch has been without update during the CF, I’m
marking this Returned with Feedback. Please re-submit a new version of the
patch to a future commitfest.

cheers ./daniel

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2017-10-02 08:23:34 Re: [PATCH] Improve geometric types
Previous Message Daniel Gustafsson 2017-10-02 07:28:20 Re: document and use SPI_result_code_string()