plr trigger on table with bytea column about plr HOT 8 CLOSED

@jottyfan what version of PL/R are you using ?

from plr.

sorry, forgot to mention:

• debian stretch (amd64)

me@local:~$ apt-cache policy postgresql-11-plr
postgresql-11-plr:
  Installiert:           1:8.4-1.pgdg90+1
  Installationskandidat: 1:8.4-1.pgdg90+1
  Versionstabelle:
 *** 1:8.4-1.pgdg90+1 500
        500 http://apt.postgresql.org/pub/repos/apt stretch-pgdg/main amd64 Packages
        100 /var/lib/dpkg/status

and

me@local:~$ apt-cache policy r-base
r-base:
  Installiert:           3.3.3-1
  Installationskandidat: 3.3.3-1
  Versionstabelle:
 *** 3.3.3-1 500
        500 http://ftp.de.debian.org/debian stretch/main amd64 Packages
        100 /var/lib/dpkg/status

from plr.

@jottyfan what is your expectation here ? The code as is does not work, but I'm curious what your use case is ?

from plr.

Thanks for your fix.

My expectation is that I can use a plr-trigger on any postgreSQL-table, even if it contains bytea-columns. Besides, I found out that on tables with text columns, entries with very large content generate the same crash. I don't know exactly what the limit was, but I think about 32k. So my solution was to generate a postgresql trigger function in plr (after insert trigger) that handles the inserted values in any way; now I do this on a replacement table (without bytea) and do a select inside of the trigger by omitting the pg.tg.new record and do a select on the table instead. In the end, this is a upload functionality to parse some big files (xls, ods, csv, ...) to fill some other database tables. Doing so in a trigger function might be a weird use case, but I'm trying to find out what is possible, and currently, it looks very well...

from plr.

Well I don't think my fix is correct, all it does is stop the crash, I don't believe it ends up with anything usable. As for text columns I find that surprising.

As for plr-triggers, I expect it would be much easier to write triggers in plpgsql and then call R from there. It would be much easier to manipulate the row in plpgsql.

Thanks,
Dave

from plr.

Well I don't think my fix is correct, all it does is stop the crash...

But for me this is a bugfix, it stops the crash. :)

As for plr-triggers, I expect it would be much easier to write triggers in plpgsql and then call R from there. It would be much easier to manipulate the row in plpgsql.

Yes, but... have you ever tried to parse an xls file with plpgsql? Doing so in R is easy, it saves me a lot of (dev) time. If I call R from plpgsql (still don't know how to do so), what was a reason to use plr then? I'd better give plr a chance.

from plr.

@jottyfan the semantics of bytea in PL/R is as follows: PL/R assumes that whatever is stored in the bytea object has been serialized by R using 'serialize'. The use case is: If you are pre-processing some data you might want to store it in a bytea object after serializing it. What this means is that unless the bytea data was a serialized R object there is no standard way for R to understand the bytes that have been stored in there. As I said you'd be better off using plpgsql and sanitizing any columns and then passing it to PL/R. You can do another select in plplgsql or in postgresql 11 you can call another procedure.

from plr.

lack of response

from plr.