On 23 August 2017 at 08:18, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Wed, Aug 23, 2017 at 10:59 AM, Masahiko Sawada <sawada.m...@gmail.com> > wrote: >> On Tue, Aug 22, 2017 at 3:23 PM, Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers