Re: Additional accessors via the Extension API ?

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Markur Sens <markursens(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Additional accessors via the Extension API ?
Date: 2022-02-20 10:35:08
Message-ID: 20220220103508.il2a3fpaeeys3mt3@jrouhaud
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.
[...]

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Markur Sens 2022-02-20 11:26:15 Re: Additional accessors via the Extension API ?
Previous Message Markur Sens 2022-02-20 10:31:22 Re: Additional accessors via the Extension API ?