Re: [HACKERS] Explicit relation name in VACUUM VERBOSE log

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Explicit relation name in VACUUM VERBOSE log
Дата
Msg-id CA+Tgmoa=3dVrNfOM43sm8Y3UjbQAkR5-b26ViGJzes8qn4Vnmg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Explicit relation name in VACUUM VERBOSE log  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: [HACKERS] Explicit relation name in VACUUM VERBOSE log  (Daniel Gustafsson <daniel@yesql.se>)
Список pgsql-hackers
On Tue, Aug 22, 2017 at 2:23 AM, Simon Riggs <simon@2ndquadrant.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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] [PATCH] Fix drop replication slot blocking instead ofreturning error
Следующее
От: David Steele
Дата:
Сообщение: [HACKERS] OpenFile() Permissions Refactor