diff options
| author | Mike Bayer <mike_mp@zzzcomputing.com> | 2019-06-15 18:06:50 -0400 |
|---|---|---|
| committer | Mike Bayer <mike_mp@zzzcomputing.com> | 2019-06-15 20:38:39 -0400 |
| commit | 009acc95b8804b5b62fbd43c6fdd61d6fd407ef7 (patch) | |
| tree | b6e8d799be87d73b3f981c7a876b8c22a18809d4 /test/dialect/postgresql/test_reflection.py | |
| parent | de08740d7c21fa9dcef453bfd07a3defa428e88f (diff) | |
| download | sqlalchemy-009acc95b8804b5b62fbd43c6fdd61d6fd407ef7.tar.gz | |
Turn off the is_literal flag when proxying literal_column() to Label
Fixed a series of quoting issues which all stemmed from the concept of the
:func:`.literal_column` construct, which when being "proxied" through a
subquery to be referred towards by a label that matches its text, the label
would not have quoting rules applied to it, even if the string in the
:class:`.Label` were set up as a :class:`.quoted_name` construct. Not
applying quoting to the text of the :class:`.Label` is a bug because this
text is strictly a SQL identifier name and not a SQL expression, and the
string should not have quotes embedded into it already unlike the
:func:`.literal_column` which it may be applied towards. The existing
behavior of a non-labeled :func:`.literal_column` being propagated as is on
the outside of a subquery is maintained in order to help with manual
quoting schemes, although it's not clear if valid SQL can be generated for
such a construct in any case.
Fixes: #4730
Change-Id: I300941f27872fc4298c74a1d1ed65aef1a5cdd82
Diffstat (limited to 'test/dialect/postgresql/test_reflection.py')
0 files changed, 0 insertions, 0 deletions