moving to -hackers since the patch is already in...
On Wednesday 05 September 2007 18:12, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > Florian G. Pflug wrote:
> >> So, in essence, you get the old pg_locks format back by doing
> >> select l1.*, l2.transactionid as "transaction" from pg_locks l1,
> >> pg_locks l2
> >> where l1.vxid = l2.vxid and l2.locktype = 'transaction'
> >> and l2.mode='exclusive' and l2.granted=true.
>
> You'd want some sort of left join, no doubt, else you're not going to
> see transactions that have not got an XID.
>
> > or make it a system view?
>
> That would be a bit silly. If there's actually still a use-case for the
> XID column then we should just put it back.
I agree, adding a system view to make up for removing a column seems like the
wrong solution to me.
> I don't actually see a
> reasonable use-case for it though. As Florian points out, you can get
> it if you really need it --- but that view is already annoyingly wide,
> and I'm not eager to burden it with columns that are usually useless.
>
I'm trying to decide how reasonable the use case is. We have transactions that
run several hours long, often touching a number of tables, and I've used the
transaction to get a list of all of the relations a given transaction is
touching. This makes the above solution more annoying by far, but I don't do
it often, and I think I generally use the pid to get that information anyway;
if I used prepared transactions I'm sure I'd feel stronger about this.
> Also, I still agree with Florian's earlier argument that we should
> deliberately break any code that's depending on the transaction column.
> Any such code is unlikely to be prepared for the column containing nulls.
>
I don't buy this argument really only so far as the column can already be
null, so apps already need a way to deal with that. I would agree that the
behavior of the column has changed, so it might cause some odd behvaior in
apps that rely on it.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL