From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Tzahi Fadida <Tzahi(dot)ML(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: CTIDs invalidations and dropping columns. |
Date: | 2006-07-11 03:24:24 |
Message-ID: | 7912.1152588264@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> You're talking about "invalidation" as if it's something someone
> deliberately does. That's incorrect. The t_ctid field is filled in if
> and only if the tuple is exactly the on disk tuple. Otherwise it's a
> new tuple, which by definition does not have a ctid (it doesn't exist
> on disk).
The only way that t_ctid would be "valid" in the result of a SELECT * FROM
is if the "physical tlist" optimization triggers to make the scan skip
the usual ExecProject call and just return a direct pointer to the
on-disk tuple. That optimization never existed before 8.0 or 8.1
(I forget exactly, but it's pretty recent). So the OP is depending
on an undocumented, recently added behavior that only applies in one
special case. To be blunt, the OP's code is broken. If you want to
know the on-disk tuple's CTID, select it explicitly:
SELECT ctid, whatever-else-you-need FROM foo ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Charles Duffy | 2006-07-11 07:25:33 | putting CHECK_FOR_INTERRUPTS in qsort_comparetup() |
Previous Message | Agent M | 2006-07-11 03:06:48 | 10th Anniversary Conference |