On Sun, Jun 10, 2012 at 12:43:31PM -0400, A.M. wrote:
> 
> On Jun 9, 2012, at 10:41 PM, Michael Bayer wrote:
> 
> > it looks great.
> > 
> > This is in the queue as http://www.sqlalchemy.org/trac/ticket/2502.
> 
> 
> 1765              text += " MATCH %s" % constraint.match 
> 
> SQL injection? Shouldn't the argument be one of three constants?
ON UPDATE, ON DELETE, DEFERRABLE, and INITIALLY all work this way. If
this is broken, then we should fix those, too. And there are other
places, like in the dialect-specific index parameters, that do this as
well. I don't agree that it's a problem, however, because if we start
saying what can appear there, we're necessarily limiting ourselves to
the lowest common denominator. PostgreSQL, for instance, supports SET
DEFAULT in ON UPDATE/DELETE, but MySQL does not. How do we handle that
case? It seems like a lot of cruft would accumulate if we start
specifying which values can go in these places.

> 
> I suspect there needs to be some specific per-database-driver logic to handle 
> unimplemented cases. PostgreSQL, for example, doesn't support MATCH PARTIAL ( 
> http://www.postgresql.org/docs/9.1/static/sql-createtable.html )
This is correct. I do not believe Oracle does either. But PostgreSQL will
courteously die with an error:
ERROR:  MATCH PARTIAL not yet implemented

> and MySQL, naturally, completely ignores the syntax and triggers other 
> clauses to be ignored:
> 
> "For users familiar with the ANSI/ISO SQL Standard, please note that no 
> storage engine, including InnoDB, recognizes or enforces the MATCH clause 
> used in referential integrity constraint definitions. Use of an explicit 
> MATCH clause will not have the specified effect, and also causes ON DELETE 
> and ON UPDATE clauses to be ignored. For these reasons, specifying MATCH 
> should be avoided."
> http://dev.mysql.com/doc/refman/5.5/en/create-table.html
I really hope someone has filed a bug report against MySQL about this.

The MySQL dialect can be patched to die with a CompileError (maybe) if
MATCH is used, which seems like the sanest option, given that it causes
unexpected behavior. I don't think the other dialects should be given
the same treatment, however, because those will presumably error out if
even given MATCH.

Can someone test this on other databases to confirm?

> 
> Cheers,
> M
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "sqlalchemy" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group at 
> http://groups.google.com/group/sqlalchemy?hl=en.
> 

-Ryan Kelly

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Reply via email to