On Tue, Aug 20, 2019 at 2:46 AM Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
>
> "Johann 'Myrkraverk' Oskarsson" <johann@xxxxxxxxxxxxxx> writes:
> > On Tue, Aug 20, 2019 at 1:32 AM Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
> >> You could manually update the pg_type row, and then if you were
> >> being fussy, add pg_depend entries showing the type depends on
> >> the functions.
>
> > Can I do this in a future proof way? That is, is there a way to make
> > that into an upgrade script, or will I make the extension
> > un-upgradable doing that?
>
> [ shrug... ] Depends what you consider "future proof". I should think
> that if pg_type.typsend goes away or changes meaning, for example,
> that would be reflective of changes large enough to break an extension
> dabbling in binary I/O in other ways anyway.
>
> Inserting new rows into pg_depend manually is a bit riskier, but I
> don't think that catalog has changed since its inception, so it's
> not all that risky.
I have updated the catalog, and the binary send and recv functions work.
The steps I took are
create function sha1_send( sha1 ) returns bytea immutable
language c strict as 'hashtypes', 'sha_send1';
update pg_type set typsend = 'sha1_send'::regproc
where typname = 'sha1';
create function sha1_recv( internal ) returns sha1 immutable
language c strict as 'hashtypes', 'sha_recv1';
update pg_type set typreceive = 'sha1_recv'::regproc
where typname = 'sha1';
Then for completeness sake, I added two rows into pg_depend with
insert into pg_depend ( classid, objid, objsubid, refclassid,
refobjid, refobjsubid, deptype )
values ( 'pg_type'::regclass::oid, 'sha1'::regtype::oid, 0,
'pg_proc'::regclass::oid, 'sha1_recv'::regproc::oid, 0, 'n' );
insert into pg_depend ( classid, objid, objsubid, refclassid,
refobjid, refobjsubid, deptype )
values ( 'pg_type'::regclass::oid, 'sha1'::regtype::oid, 0,
'pg_proc'::regclass::oid, 'sha1_send'::regproc::oid, 0, 'n' );
Before I roll all of that into an upgrade script for the other sha
types, is there something else I should be doing?
I did not dare to try before adding to pg_depend, but here's what
happens when I try to drop function sha1_recv;
ERROR: cannot drop function sha1_recv(internal) because other
objects depend on it
DETAIL: extension hashtypes depends on function sha1_recv(internal)
column passwd of table pwned depends on type sha1
function sha1_send(sha1) depends on type sha1
Does this look correct?
> In any case, you could limit the lifespan of the upgrade script,
> if you roll it up into a new base install script ASAP.
I am not the maintainer of the extension, and I'll see what I can do.
--
Johann
I'm not from the internet, I just work there.
