From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
Cc: | josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org, "Jim C(dot) Nasby" <jimn(at)enterprisedb(dot)com> |
Subject: | Re: 8.2 beta blockers |
Date: | 2006-09-18 20:53:51 |
Message-ID: | 4325.1158612831@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Merlin Moncure" <mmoncure(at)gmail(dot)com> writes:
> sure no problem. the prototypes you suggested are imo the way to go,
> with two small considerations:
> is it worth considering using the oid type instead of int4 since the
> 'locktag' fields are unsigned?
Hmm ... I was thinking it didn't matter, but on closer look, the
int4->oid cast is implicit while the oid->int4 one is only assignment.
So you'd need to write a cast to pass an OID if we declare the functions
as taking int4. But you'll need a cast anyway if you want to pass a
single OID to the int8-taking version (that's an assignment cast too).
The downside of declaring the functions to take OID is that people might
think they could *only* use OIDs, which isn't so, they can use any
int4-sized key they feel like.
Not seeing a strong reason one way or the other ... what do you think?
> also, the userlocks raised a warning if you tried to release a
> non-existing lock. should that stay or go?
That's in the core code I think, so it won't change.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2006-09-18 20:54:01 | Re: Release notes |
Previous Message | Josh Berkus | 2006-09-18 20:44:55 | Re: 8.2 beta blockers |