On 23 August 2017 at 08:18, Michael Paquier <michael.paquier@gmail.com> wrote:
> On Wed, Aug 23, 2017 at 10:59 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>> On Tue, Aug 22, 2017 at 3:23 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> e.g.
>>> replace RelationGetRelationName() with
>>> RelationGetOptionallyQualifiedRelationName()
>>> and then control whether we include this new behaviour with
>>> log_qualified_object_names = on | off
>>
>> Is there any case where we don't want to get non-qualified object
>> names? If users want to get the same log message as what they got so
>> far, it would be better to have a GUC that allows us to switch between
>> the existing behavior and the forcibly logging qualified object names.
>
> I can imagine plenty of cases where providing more information is
> valuable, but not really any where it makes more sense to provide less
> information, so -1 for a GUC to control such behavior. I would imagine
> that people are not going to set it anyway. A RangeVar may not set the
> schema_name, so I would suggest to rely on that to decide if the error
> messages show the schema name or name.
We can put in the GUC if there are objections about backwards
compaibility, so I am OK to leave it out.
> Still we are only talking about
> two messages in the vacuum code paths, which are the ones close to the
> checks where is assigned the OID of the relation with a RangeVar.
The proposal is to change all log messages so we have consistency, not
just VACUUM.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services