On Sun, Aug 31, 2014 at 02:10:33PM -0400, Tom Lane wrote:
> David G Johnston <david.g.johns...@gmail.com> writes:
> > Would it be proper to issue an additional top-level warning with the column
> > moved notification?  Thus there would be NOTICE, NOTICE, WARNING in the
> > above example?  Or, more generically, "columns reordered to match inherited
> > column order" to avoid multiple warnings if more than one column is moved.
> 
> That's a good point: if this message fires at all, it will probably fire
> more than once; do we want that?  If we do it as you suggest here, we'll
> lose the information as to exactly which columns got relocated, which
> perhaps is bad, or maybe it doesn't matter.  Also, I don't remember the
> exact code structure in that area, but it might be a bit painful to
> arrange that we get only one such warning even when inheriting from
> multiple parents.
> 
> If we do want the specific moved columns to be identified, I'd still go
> with errdetail on the NOTICE rather than two separate messages.  I think
> calling it a WARNING is a bit extreme anyway.

OK, here is the updated output based on the comments:

        CREATE TABLE B(a int, c int);
        CREATE TABLE a5 (
            a integer,
            b integer,
            c integer
        )
        INHERITS (b);
        NOTICE:  merging column "a" with inherited definition
        NOTICE:  moving and merging column "c" with inherited definition
        DETAIL:  user-specified column moved to the location of the inherited
        column

I think we have to mention "move" in the error message because
mentioning "move" only in the detail means that the detail actually has
new information, not more detailed information.

Patch attached.

-- 
  Bruce Momjian  <br...@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
new file mode 100644
index 3720a0f..b88b664
*** a/src/backend/commands/tablecmds.c
--- b/src/backend/commands/tablecmds.c
*************** MergeAttributes(List *schema, List *supe
*** 1756,1767 ****
--- 1756,1771 ----
  	 */
  	if (inhSchema != NIL)
  	{
+ 		int		schema_attno = 0;
+ 
  		foreach(entry, schema)
  		{
  			ColumnDef  *newdef = lfirst(entry);
  			char	   *attributeName = newdef->colname;
  			int			exist_attno;
  
+ 			schema_attno++;
+ 
  			/*
  			 * Does it conflict with some previously inherited column?
  			 */
*************** MergeAttributes(List *schema, List *supe
*** 1780,1788 ****
  				 * Yes, try to merge the two column definitions. They must
  				 * have the same type, typmod, and collation.
  				 */
! 				ereport(NOTICE,
! 				   (errmsg("merging column \"%s\" with inherited definition",
! 						   attributeName)));
  				def = (ColumnDef *) list_nth(inhSchema, exist_attno - 1);
  				typenameTypeIdAndMod(NULL, def->typeName, &defTypeId, &deftypmod);
  				typenameTypeIdAndMod(NULL, newdef->typeName, &newTypeId, &newtypmod);
--- 1784,1797 ----
  				 * Yes, try to merge the two column definitions. They must
  				 * have the same type, typmod, and collation.
  				 */
! 				 if (exist_attno == schema_attno)
! 					ereport(NOTICE,
! 					   (errmsg("merging column \"%s\" with inherited definition",
! 							   attributeName)));
! 				else
! 					ereport(NOTICE,
! 					   (errmsg("moving and merging column \"%s\" with inherited definition", attributeName),
! 						errdetail("user-specified column moved to the location of the inherited column")));
  				def = (ColumnDef *) list_nth(inhSchema, exist_attno - 1);
  				typenameTypeIdAndMod(NULL, def->typeName, &defTypeId, &deftypmod);
  				typenameTypeIdAndMod(NULL, newdef->typeName, &newTypeId, &newtypmod);
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to