[sqlalchemy] Re: FAQ for CREATE TABLE output incomplete
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. -- 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.
Re: [sqlalchemy] Re: FAQ for CREATE TABLE output incomplete
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))),
for the array, you need to use postgresql.array(), not func.array().
It will work like this:
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.
--
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.
Re: [sqlalchemy] Re: FAQ for CREATE TABLE output incomplete
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.
Re: [sqlalchemy] Re: FAQ for CREATE TABLE output incomplete
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.
[sqlalchemy] Re: FAQ for CREATE TABLE output incomplete
I may have spoken too soon. It seems that metadata.create_all() does not handle this correctly either. I'm trying to see if this affects the latest version of SQLAlchemy. -- 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.
