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.
