On Monday, September 3, 2012, Michael Bayer wrote: > > On Sep 3, 2012, at 11:22 AM, Eric Lemoine wrote: > > > On Mon, Sep 3, 2012 at 4:29 PM, Michael Bayer > > <mike...@zzzcomputing.com<javascript:;>> > wrote: > >> oh. yeah it's going to have to not do that. try out tip, it will > only put the type expression on those columns being delivered to the result > (i.e. the outermost). > > > > I didn't think you'd fix that one. You rock. Thanks. > > yeah the whole system is based on the ability to know when a column is > being rendered "for the result", i.e. the top level, so as these SQL > functions are to augment the usual "process_result_value()" system it > follows that these "in-SQL processing" functions only need to be at that > level as well. It was a one line change.
result_processor and column_expression are companions, and relate to the "result". That makes sense. -- Eric Lemoine Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac, Cedex Tel : 00 33 4 79 44 44 96 Mail : eric.lemo...@camptocamp.com http://www.camptocamp.com -- 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.
