It turns out that that is exactly what was happening already.  The $1
was being blanked (as it should be) but the MySQL producer wasn't
handling it properly (the postgres and oracle producers handled it just
fine).

I've modified the foreign key constraint name so that if it is blank, it
will default to TABLENAME_fk (as opposed to being named "_1", "_2",...
as it was doing).

If anyone thinks this isn't how that should be handled, please let me
know.

BTW, I believe this fixes Brian's original problem.  Although, the
PostgreSQL parser isn't handling pg_dump output of his schema using
postgres 8.2.4.  So I don't really consider the issue closed.  There are
a few changes that will need to be made to the postgres parser to get it
up to date.

Ben

On Fri, 2007-11-09 at 13:07 -0500, Hilmar Lapp wrote:
> I'd say that if no name was originally provided for the constraint,  
> then the parse should ideally reflect that fact truthfully (such that  
> a producer would also let the name default to whatever the target  
> will use).
> 
>       -hilmar
> 
> On Nov 9, 2007, at 10:10 AM, Ben Faga wrote:
> 
> >
> >
> > 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
> 


-------------------------------------------------------------------------
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

Reply via email to