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