I've not been able to duplicate this in a standalone script yet,=20
but in the guts of Bucardo is a trigger function called validate_goat()=20
that is giving this error on 9.1 HEAD, but not on previous versions:
"Failed to add table "public.pgbench_tellers": DBD::Pg::st execute=20
failed: ERROR: Modification of non-creatable hash value attempted,=20
subscript "pkey" at line 4."
I was able to simplify the function to just this and still produce=20
the error:
CREATE OR REPLACE FUNCTION bucardo.validate_goat()
RETURNS TRIGGER
LANGUAGE plperlu
AS
$bc$
my $new =3D $_TD->{new};
$new->{pkey} =3D 'foobar';
return 'MODIFY';
$bc$;
It's used like this:
CREATE TRIGGER validate_goat
BEFORE INSERT OR UPDATE ON bucardo.goat
FOR EACH ROW EXECUTE PROCEDURE bucardo.validate_goat();
The goat table has many text fields, of which one is=20
pkey. Setting it to any of those other columns will cause the error.=20
However, setting it to a text field that is NOT NULL DEFAULT will=20
*not* produce the error, so obviously something is setting=20
$_TD->{new}{somecol} to undef in the wrong way. I'm baffled as=20
to why I cannot reproduce it standalone, but wanted to get the=20
bug out there so I don't forget about it and in case anyone=20
wants to take a swing at it. Some Googling suggests it might=20
be because we are using &PL_sv_undef instead of a proper=20
newSV(0).
--=20
Greg Sabino Mullane greg@endpoint.com
End Point Corporation
PGP Key: 0x14964AC8
