On May 5, 2012, at 7:33 PM, Ryan Kelly wrote: > List: > > I am currently trying to add support for FROM ONLY to the postgresql > dialect. FROM ONLY is used when you wish to query a table which has > other tables that inherit from it, but you ONLY want results from the > parent table you are referencing. More information can be found here: > http://www.postgresql.org/docs/current/static/sql-select.html#SQL-FROM
OK, this looks like a nice patch, though I'm not sure it's consistent with how we've approached this kind of SQL feature in other cases. "ONLY" looks a lot like an optimization hint added to the FROM clause. We already have an API for this, called with_hint(). with_hint() is intended to be supported by all of INSERT, UPDATE, DELETE in addition to SELECT. I'm not sure at the moment what it does with PG right now but it might be a more appropriate approach. Take a look and let me know if you have thoughts on that. > > During the course of implementing this, I found that the visit_delete > method did not call _compiler_dispatch on the table targeted by the > delete, preventing table aliases in a delete, and preventing my > implementation of ONLY for delete. I changed this, but the mssql dialect > has some strange aliasing rules, which needed some TLC to function > correctly in the presence of _compiler_dispatch. Also it seems a little awkward that DELETE now defers to generic compilation to format the table, but still not INSERT or UPDATE which still hardcode to preparer.format_table(). > > Of course, table aliasing in a delete isn't supported by all dialects, > and my current implementation doesn't do anything to protect Jimmy[1]. is aliasing of a table also a different feature need here ? Which DBs support this ? > > So there are two patches attached to this email, the first being for > _compiler_dispatch in visit_delete (compiler_dispatch_deletes.patch) > and the other for FROM ONLY in postgres (from_only.patch). The second > one could probably be considering more of a work-in-progress and I'm > actually interested in feedback on whether or not I'm headed in the > right direction with it. It also depends on the first patch. > > Also, is this the right list? sure, there's also sqlalchemy-devel, though for features/patches you can also use trac tickets or bitbucket forks/pull requests.... thanks for the patches and interest ! > > -Ryan Kelly > > [1] http://www.globalnerdy.com/2010/05/09/new-programming-jargon/ > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To post to this group, send email to sqlalchemy@googlegroups.com. > To unsubscribe from this group, send email to > sqlalchemy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. > > <compiler_dispatch_deletes.patch><from_only.patch> -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
