From: Tom Lane <tgl@sss.pgh.pa.us>
To: achill@matrix.gatewaynet.com
Cc: pgsql-hackers@postgresql.org
Cc: pgsql-sql@postgresql.org
Subject: Re: HeapTuple->t_tableOid==0 after SPI_exec
Date: Fri, 03 Oct 2003 10:43:36 -0400
Message-ID: <19369.1065192216@sss.pgh.pa.us> (raw)
In-Reply-To: <Pine.LNX.4.44.0310031546360.5168-100000@matrix.gatewaynet.com>
References: <Pine.LNX.4.44.0310031546360.5168-100000@matrix.gatewaynet.com>
achill@matrix.gatewaynet.com writes:
> When HeapTuple is populated by
> SPI_exec("select * from foobar when id=667");
> tuple = SPI_tuptable->tvals[0] (id is PK and row with 667 exists)
> then tuple->t_tableOid is always 0.
The result of a SELECT is never a raw table tuple, not even when it's a
straight "select * from foo". It's a constructed tuple that belongs to
no particular table --- which makes sense because in general it wouldn't
match any particular table's rowtype.
I think in 7.4 there may be an optimization that skips the tuple
projection step in this particular case, but if you can in fact see
t_tableOid in 7.4, it'd be an implementation artifact rather than
something we will promise to support in future. The correct way if you
want to see tableoid is to select it:
select tableoid,* from foobar where ...
and then extract it from the result using the usual field-access
routines.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: tgl@sss.pgh.pa.us, achill@matrix.gatewaynet.com, pgsql-hackers@postgresql.org
Subject: Re: HeapTuple->t_tableOid==0 after SPI_exec
In-Reply-To: <19369.1065192216@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox