On 6/18/14, 12:03 PM, Ryan Kelly wrote: > On Wed, Jun 18, 2014 at 11:15 AM, Mike Bayer <mike...@zzzcomputing.com> wrote: >> On 6/18/14, 2:06 AM, rpkelly wrote: >>> It seems like passing literal_binds=True to the call to >>> sql_compiler.process in get_column_default_string will work, so long >>> as SQLAlchemy can convert the values to literal binds. Which, in the >>> example given, isn't the case. >> the long standing practice for passing literals into server_default and >> other places is to use literal_column(): >> >> server_default=func.foo(literal_column("bar"))), > The issue with this is that in my actual code, the values are read > from somewhere else, so > I was trying to find a safe way to use them without having to deal > with quoting/escaping > issues so my code is Jimmy-proof > >> for the array, you need to use postgresql.array(), not func.array(). >> It will work like this: > When I created the example, I changed the name of the function from > "make_array" to "array". > So it actually is a function call to make_array, so it seems I need to > put postgresql.array() > inside of func.make_array() (or use the variadic form and unpack the list). > >> tbl = Table("derp", metadata, >> Column("arr", ARRAY(Text), >> server_default=array([literal_column("'foo'"), >> literal_column("'bar'"), >> literal_column("'baz'")])), >> ) >> >> the docs suck. >> https://bitbucket.org/zzzeek/sqlalchemy/issue/3086/server_default-poorly-documented >> is added (referring to >> http://docs.sqlalchemy.org/en/rel_0_9/core/defaults.html#server-side-defaults). >> >> then for literal_binds. We've been slowly adding the use of this new >> parameter with a fair degree of caution, both because it can still fail >> on any non-trivial kind of datatype and also because a feature that >> bypasses the "bound parameter" logic is just something we've avoided for >> years, due to the great security hole it represents. We added it for >> index expressions in #2742. >> https://bitbucket.org/zzzeek/sqlalchemy/issue/3087/literal_binds-in-server_default >> will add it for server_default. it's 1.0 for now but can be >> potentially backported to 0.9.5. > Right, but I also don't think it's safe to issue DDL with arbitrary > input as it currently stands, > even values which are correctly escaped/formatted/etc. might result in > name collisions or > shadowing, or other undesirable behavior. I'm not sure if the > documentation makes a > statement about issuing DDL using information from untrusted sources, > but it probably should. We are already rendering expressions in Index objects with inline literals. I'm not sure under what scenario rendering bounds as literals would produce a name collision. As far as DDL from untrusted sources, certainly we could add language for that, though a system that is rendering DDL on the fly from untrusted input (as opposed to, some kind of schema-construction tool that trusts the user) is so crazy that I doubt those folks read the docs that carefully anyway :).
> > -Ryan Kelly > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.