> On 20 Feb 2022, at 12:12 PM, Julien Rouhaud <rjuju123@xxxxxxxxx> 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.
