X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.130]) by svr1.postgresql.org (Postfix) with ESMTP id B0B0FD1B55C; Fri, 3 Oct 2003 14:44:24 +0000 (GMT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024) with ESMTP id 62994-05; Fri, 3 Oct 2003 11:43:38 -0300 (ADT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by svr1.postgresql.org (Postfix) with ESMTP id 954ADD1B54B; Fri, 3 Oct 2003 11:43:34 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.10/8.12.10) with ESMTP id h93Ehahn019370; Fri, 3 Oct 2003 10:43:36 -0400 (EDT) To: achill@matrix.gatewaynet.com Cc: pgsql-hackers@postgresql.org, pgsql-sql@postgresql.org Subject: Re: HeapTuple->t_tableOid==0 after SPI_exec In-reply-to: References: Comments: In-reply-to achill@matrix.gatewaynet.com message dated "Fri, 03 Oct 2003 15:56:07 +0300" Date: Fri, 03 Oct 2003 10:43:36 -0400 Message-ID: <19369.1065192216@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200310/43 X-Sequence-Number: 15443 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