fix: Fix crash caused by trigger function and bytea column fixes #63

[davecramer]

This stops the crash from happening but I'm unclear that we should be stuffing a string into raw.

comments ?

[jconway]

I'll try to look at this over the weekend (likely not until Sunday). The main question in my mind is why has this not been reported before -- i.e. is it a long standing latent bug that has never been reported before or is it something new induced by changes in postgres. And if the latter, what changes caused it.

[davecramer]

Looks like a long standing latent bug. I looked at git history and of that file and it seems we have been treating BYTEA and TEXT the same way there forever. Pretty sure this is not the solution but I'm unclear how to serialize a null into raw. Thanks for looking at it.

[mlt]

It would be nice to test this as well.

I'm unclear how to serialize a null into raw

Isn't NULL just R_NilValue at all times?

I'm unclear that we should be stuffing a string into raw

I feel like it should be as verbatim as possible. So if string is hex or escape encoded representation for bytea, it should be decoded back and then, perhaps, be unserialized.

I started an attempt to do R to PG data passing without intermediate C string representation. I think the same ideally should be done when passing from PG to R as well (sans ALTREP).

[davecramer]

Hi Mikhail, Null is easy. So talking with Joe the way this is *supposed* to work is that R really only understands something that it has serialized so whatever is in the bytea has to be the result of serialize otherwise whatever we do unserialize will be unintelligible to any R program. I have to get back to this but basically there's no real way to handle any arbitrary bytea column in R. Thanks, Dave Cramer

…

On Wed, 3 Jul 2019 at 15:46, Mikhail Titov ***@***.***> wrote: It would be nice to test this as well. I'm unclear how to serialize a null into raw Isn't *NULL* just *R_NilValue* at all times? I'm unclear that we should be stuffing a string into raw I feel like it should be as verbatim as possible. So if string is hex or escape encoded representation for bytea, it should be decoded back and then, perhaps, be unserialized. I started an attempt to do R to PG data passing without intermediate C string representation <https://github.com/mlt/plr/blob/refactor/r_to_pg.c#L232>. I think the same ideally should be done when passing from PG to R as well (sans ALTREP). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#64?email_source=notifications&email_token=AADDH5UJIRTW3BVLTCOOTSLP5T6Y5A5CNFSM4H2RK632YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZFP3XY#issuecomment-508231135>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADDH5XBPEMJQJSFBXNMMXTP5T6Y5ANCNFSM4H2RK63Q> .

[mlt]

whatever is in the bytea has to be the result of serialize

I agree! I think the behavior should be consistent with pg_scalar_get_r