Re: Additional accessors via the Extension API ?

> On 20 Feb 2022, at 12:12 PM, Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
>
> Hi,
>
> On Sun, Feb 20, 2022 at 08:07:20AM +0200, Markur Sens wrote:
>> Suppose I have defined an additional type in a PG extension.
>>
>> Is it possible to add custom accessors to that type -much like jsonb does-
>> but use an API/hook without touching the core PG grammar & parser?
>
> Unfortunately no.
>
>> Hypothetical Examples:
>>
>> Assuming I have a TextFile type I’d like to implement syntax like:
>>
>> (‘/home/me/a.txt’::TextFile).firstline
>> (‘/home/me/a.txt’::TextFile).lastline
>> (‘/home/me/a.txt’::TextFile).countlines()
>> (‘/home/me/a.txt’::TextFile).size()
>> (‘/home/me/a.txt’::TextFile).datemodified()
>
> 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?

>
> # create function f1(int) returns text as $$
> begin
> return 'val: ' || $1::text;
> end;
> $$ language plpgsql;
>
> # create table t as select 1 as id;
>
> # select (5).f1, (id).f1 from t;
> f1 | f1
> --------+--------
> val: 5 | val: 1
> (1 row)
>
> I don't know if that would be enough for you needs. Otherwise, the only option
> would be tocreate an operator instead, like mytype -> 'myaccessor' or something
> like that.

Yes, that’s what I’m doing at the moment:
Syntax like type -> ‘accessor’ is pretty straight forward to implement as an operator as the rightarg is text.

Things get more complicating as I’m adding support for
mytype -> function(arg=1)

for that case I have to create an intermediate type of function(arg) so that I can then define the left and right args for the -> operator.
But it’s a lot of boilerplate code.