From 62084ba5b02e497b1bfe6a62a3d79e8085b1c2be Mon Sep 17 00:00:00 2001 From: Federico Caselli Date: Thu, 22 Apr 2021 22:12:10 +0200 Subject: [PATCH] Suggest ``literal_column`` instead of ``text`` for column elements the next section in the tutorial discusses literal_column() already so this paragraph will just add some additional encouragement to read on. References: #6343 Change-Id: Iadaf84d80071e73eb2d0b7421a60e1790ecd0862 --- doc/build/core/tutorial.rst | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/doc/build/core/tutorial.rst b/doc/build/core/tutorial.rst index fc2f524eb3..2ef10096ea 100644 --- a/doc/build/core/tutorial.rst +++ b/doc/build/core/tutorial.rst @@ -1163,10 +1163,14 @@ need to refer to any pre-established :class:`_schema.Table` metadata: [...] ('%@aol.com', '%@msn.com') {stop}[(u'Wendy Williams, wendy@aol.com',)] -.. versionchanged:: 1.0.0 - The :func:`_expression.select` construct emits warnings when string SQL - fragments are coerced to :func:`_expression.text`, and :func:`_expression.text` should - be used explicitly. See :ref:`migration_2992` for background. + +While :func:`_expression.text` can be used in the column list of a +:func:`_expression.select` object, it has some restriction when composing the +generated select, since it will not be in +:attr:`_expression.SelectBase.selected_columns` collection and will be omitted +from the ``.c`` collection of subqueries. The next section will introduce the +:func:`_expression.literal_column` construct which is the better choice to +express individual column names as SQL fragments. -- 2.47.3