]> git.ipfire.org Git - thirdparty/sqlalchemy/sqlalchemy.git/commitdiff
ensure intro to "functions have types" is not misleading
authorMike Bayer <mike_mp@zzzcomputing.com>
Sat, 6 Jul 2024 16:24:51 +0000 (12:24 -0400)
committerMike Bayer <mike_mp@zzzcomputing.com>
Sat, 6 Jul 2024 16:25:46 +0000 (12:25 -0400)
make sure it's clear that there is normally not a return type
for SQL functions

Fixes: #11578
Change-Id: Ia0b66e7fe685dad427822345dd232eb47a0fc44f
(cherry picked from commit e9d3e49601d011f9a3471921729728ca688e04b9)
(cherry picked from commit 5e495e16da87644bcb07aa76c9021d486053b81d)

doc/build/tutorial/data_select.rst

index b34ab648cd38a429991a71e5a170ef29e2e1c38d..a47b0ca4edcef9c988e9980e96fcfb9d53e3f90b 100644 (file)
@@ -1396,11 +1396,18 @@ as opposed to the "return type" of a Python function.
 
 The SQL return type of any SQL function may be accessed, typically for
 debugging purposes, by referring to the :attr:`_functions.Function.type`
-attribute::
+attribute; this will be pre-configured for a **select few** of extremely
+common SQL functions, but for most SQL functions is the "null" datatype
+if not otherwise specified::
 
+    >>> # pre-configured SQL function (only a few dozen of these)
     >>> func.now().type
     DateTime()
 
+    >>> # arbitrary SQL function (all other SQL functions)
+    >>> func.run_some_calculation().type
+    NullType()
+
 These SQL return types are significant when making
 use of the function expression in the context of a larger expression; that is,
 math operators will work better when the datatype of the expression is