From 024a0a48c65f4acbbabf85b896470a5868ec48d3 Mon Sep 17 00:00:00 2001 From: Mike Bayer Date: Sat, 6 Jul 2024 12:24:51 -0400 Subject: [PATCH] ensure intro to "functions have types" is not misleading 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 | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/doc/build/tutorial/data_select.rst b/doc/build/tutorial/data_select.rst index b34ab648cd..a47b0ca4ed 100644 --- a/doc/build/tutorial/data_select.rst +++ b/doc/build/tutorial/data_select.rst @@ -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 -- 2.47.2