> So after writing the code to handle named NOT NULL constraints for
> tables, I'm thinking that dumpConstraints needs to be fixed thusly:
>
> @@ -12888,6 +12968,27 @@ dumpConstraint(Archive *fout, ConstraintInfo
> *coninfo)
> NULL, NULL);
> }
> }
> + else if (coninfo->contype == 'n' && tbinfo)
> + {
> + /* NOT NULL constraint on a table */
> + if (coninfo->separate)
> + {
> + write_msg(NULL, "NOT NULL constraints cannot be dumped separately
> from their owning table\n");
> + exit_nicely();
> + }
> + }
> + else if (coninfo->contype == 'n' && tbinfo == NULL)
> + {
> + /* NOT NULL constraint on a domain */
> + TypeInfo *tyinfo = coninfo->condomain;
> +
> + /* Ignore if not to be dumped separately */
> + if (coninfo->separate)
> + {
> + write_msg(NULL, "NOT NULL constraints cannot be dumped separately
> from their owning domain\n");
> + exit_nicely();
> + }
> + }
> else
> {
> write_msg(NULL, "unrecognized constraint type: %c\n",
> coninfo->contype);
>
Some nit-picking.
AFAICS above, we seem to be only using 'tbinfo' to identify the object
type here - 'table' visavis 'domain'. We could probably reduce the
above two elses to a single one and use the check of tbinfo being not
null to decide which object type name to spit out..
Although, it's difficult to see how we could end up marking NOT NULL
constraints as 'separate' ever. So this code will be rarely exercised,
if ever IMO.
Regards,
Nikhils
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
