On Sat, Mar 11, 2017 at 2:14 PM Andres Freund wrote:
> On 2017-03-11 04:31:16 +, Eric Ridge wrote:
> > Well shoot. That kinda spoils my plans.
>
> I think you should elaborate on what you're trying to achieve -
> otherwise our advice will be affected by the recent, widely reported,
> crystal
On 2017-03-11 04:31:16 +, Eric Ridge wrote:
> Well shoot. That kinda spoils my plans.
I think you should elaborate on what you're trying to achieve -
otherwise our advice will be affected by the recent, widely reported,
crystal ball scarcity.
- Andres
--
Sent via pgsql-hackers mailing lis
On 3/10/17 10:31 PM, Eric Ridge wrote:
What about this? Is the tuple currently being evaluated (I suppose in
the case of a sequential scan) available in the context of a function call?
AFAIK that *very* specific case would work, because the executor would
be handing you the raw tuple. Not a g
>
> I suspect the tuple at (0,1) has been the subject of a failed update.
>
Yep.
> Your problem here is that you're mistaking the t_ctid field of a tuple
> header for the tuple's address. It is not that; it's really just garbage
> normally, and is only useful to link forward to the next version
Eric Ridge writes:
> What I'm seeing is that the ctid returned from this function isn't always
> correct:
> # select ctid, foo(table) from table limit 10;
> ctid |foo
> ---+---
> (0,1) | (19195,1)-- not correct!
> (0,2) | (0,2)
> (0,3) | (0,3)
I suspect the tuple at (0,1
This is about Postgres 9.6...
I have a very simple 1-arg function, in C, that I want to return the ctid
of the record passed in. Example:
CREATE OR REPLACE FUNCTION foo(record) RETURNS tid LANGUAGE c IMMUTABLE
STRICT AS 'my_extension';
Its implementation is simply:
Datum foo(PG_FUNCTION_ARGS)