> On 20 Feb 2022, at 12:35 PM, Julien Rouhaud <rjuju123@xxxxxxxxx> wrote: > > On Sun, Feb 20, 2022 at 12:31:22PM +0200, Markur Sens wrote: >>> >>> Maybe you could rely on some old grammar hack to have something a bit similar, >>> as (expr).funcname is an alias for funcname(expr). For instance: >> >> Is this documented & expected behavior or it’s just happens to work? > > I don't think it's documented but it's an expected behavior, see > > https://github.com/postgres/postgres/blob/master/src/backend/parser/parse_func.c#L57-L88 > Ah thanks for this > /* > * Parse a function call > * > * For historical reasons, Postgres tries to treat the notations tab.col > * and col(tab) as equivalent: if a single-argument function call has an > * argument of complex type and the (unqualified) function name matches > * any attribute of the type, we can interpret it as a column projection. and the (unqualified) function name matches * any attribute of the type, we can interpret it as a column projection. > * Conversely a function of a single complex-type argument can be written > * like a column reference, allowing functions to act like computed columns. > * > * If both interpretations are possible, we prefer the one matching the > * syntactic form, but otherwise the form does not matter. > * > * Hence, both cases come through here. If fn is null, we're dealing with > * column syntax not function syntax. In the function-syntax case, > * the FuncCall struct is needed to carry various decoration that applies > * to aggregate and window functions. > [...]
