Re: Additional accessors via the Extension API ? - Mailing list pgsql-general

From Julien Rouhaud
Subject Re: Additional accessors via the Extension API ?
Date
Msg-id 20220220103508.il2a3fpaeeys3mt3@jrouhaud
Whole thread Raw
In response to Re: Additional accessors via the Extension API ?  (Markur Sens <markursens@gmail.com>)
Responses Re: Additional accessors via the Extension API ?
Re: Additional accessors via the Extension API ?
List pgsql-general
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

/*
 *    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.
 *    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.
[...]



pgsql-general by date:

Previous
From: Markur Sens
Date:
Subject: Re: Additional accessors via the Extension API ?
Next
From: Markur Sens
Date:
Subject: Re: Additional accessors via the Extension API ?