On Sat, Feb 25, 2006 at 10:52:48PM -0800, Stephan Szabo wrote:
| > * Forbidding the creation of a foreign key constraint where
| > the column list for the referenced table doesn't *exactly*
| > match a canidate key on that table.
|
| About the best we're likely to be able to do is change pg_dump to dump
| it in the 03 order and possibly give an optional way to turn on an exact
| check (default off) for the next version, probably changing the default
| 1 or 2 versions after that.
Excellent.
| > * Issue a warning when creating a constraint who's name is
| > not unique within its (the constraint's) schema.
|
| I don't have a problem with it (once, I argued for following the spec
| constraint on this way back when), however I think this was proposed and
| rejected before as excess noise. You might want to look back through the
| archives.
I think the problem /w the noise was that default trigger names were
not automatically prefixed with the table name. I'd like to see this
warning; perhaps in the next release, the ``dump`` module can rename
constraints like $1 and $2 to include the table name?
Given that both of these issues consist of first changing the dumper and
making an optional warning (at first) and then turning it into an error
way down the line, could they be considered part of the same ticket?
On Sat, Feb 25, 2006 at 10:52:48PM -0800, Stephan Szabo wrote:
| Personally, I disagree with the 03 requirement and think that it's more an
| example of them misdesigning the information schema, but we should
| probably move in that direction for compatibility with more recent
| versions of spec.
Agreed; there is no reason why the information_schema could not have
been improved to add an additional view to provide this information.
On Sun, Feb 26, 2006 at 12:57:13PM -0500, Tom Lane wrote:
| This thread is fairly interesting since we appear to be watching the SQL
| committee allowing a brain-dead choice in the initial information_schema
| design to force a non-backwards-compatible dumbing-down of the main spec.
I'm glad that this thread has not been an undue burden; I'm greatful
for your help (as I'm writing an application that is attempting to
follow the specification as closely as possible).
Best,
Clark
