The issue:
The pg_dump of Postgres 7.3 uses $1 (and $2,...) as a foreign key constraint name when none was originally provided. Then when postgres interprets the file, it give the constraint the name TABLENAME_COLUMNNAME_fkey (although presumably it would handle it differently if there was a clash). The solution that I can't work out how to code: I was thinking that the PostgreSQL parser should recognize the $\d+ variables as what they are and interpret foreign key names for them. Ideally, the code for renaming a constraint would go in either the definitions for "constraint_name" or "table_constraint". However, I can't think of how these definitions would be able to access the table name to do the renaming. Alternative Solution: The parse could just blank the name and let the producers handle the naming. Maybe the is the better solution but the MySQL producer just names them "_1", "_2",... Not really the prettiest. Does anyone have any thoughts? Ben ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- sqlfairy-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sqlfairy-developers
