Constantine Peresypkin

Workaround is: ``` create or replace function trg1() returns trigger as $$ plv8.execute(`insert into t1 select * from json_populate_record(null::t1, $1)`, [NEW]); return NEW; $$ language plv8; ``` But it looks...

Ok, looks like plv8 `DoCall()` doesn't call `SPI_register_trigger_data()` when doing the SPI connection from trigger. Need to fix that, PR incoming, later. :)

Ooof, it's not helping, they do some black magic in plpgsql to parse the query in presence of these _named_ records.

> and yeah, named records passing automatically into queries is something I wouldn't be excited about. That's the behavior of plpgsql Obviously there is no problem using named records in...

I would like to see such an interface. But I think securing it will be a pretty tough matter. Currently postgres has pretty tight and versatile security controls (RLS ftw!)...

@felixge did some research, RLS is applied at a query rewrite phase. I.e. it's a pretty high abstraction...

@felixge it's a query rewrite phase, you will need to produce actual SQL query and then rewrite it using rls rewriter and only then you can invoke the executor. While...

P.S. you know what. I think plugging into FDW may be a faster way to get results. Pity that there is no FDW implementation for V8/javascript right now...

> I will note that there's a thread on pg-hackers about how slow using SPI is, so there might be some gain to having an alternate path into the executor....

> alternate path into the executor Actually I need some sort of custom executor because otherwise it's nearly impossible to bill users on postgres usage. Even getting the disk space...