Joe Conway <[EMAIL PROTECTED]> writes:
> But BuildDescForRelation leaves initializes the tupdesc like this:
>desc = CreateTemplateTupleDesc(natts, UNDEFOID);
> The UNDEFOID later causes an assertion failure in heap_formtuple when
> you try to use the tupdesc to build a tuple.
So far, I have
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
>>Attached adds:
>> + TupleDesc queryDesc; /* descriptor for planned query */
>>to ReturnSetInfo, and populates ReturnSetInfo for every function call to
>> ExecMakeTableFunctionResult, not just when fn_retset.
>
> I thought "expectedDes
Joe Conway <[EMAIL PROTECTED]> writes:
> Attached adds:
>+ TupleDesc queryDesc; /* descriptor for planned query */
> to ReturnSetInfo, and populates ReturnSetInfo for every function call to
> ExecMakeTableFunctionResult, not just when fn_retset.
I thought "expectedDesc" was a more sensible
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
>>Preference of extending FunctionCallInfoData or ReturnSetInfo?
>
> Definitely ReturnSetInfo. If we put it in FunctionCallInfoData then
> that's an extra word to zero for *every* fmgr function call, not only
> table functions.
Attached a
Joe Conway <[EMAIL PROTECTED]> writes:
>> On the other hand, your experience yesterday with debugging a mismatched
>> function declaration suggests that it's still a good idea to make the
>> functions build the tupdesc they think they are returning.
> In a function which *can* know what the tuple
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
>>Actually, I left off trying to figure out how to pass the columndef to
>>ExecMakeFunctionResult in the first place.
>
> That was hard yesterday, but it's easy today because nodeFunctionscan
> isn't using ExecEvalExpr anymore --- we'd onl
Tom Lane wrote:
> I've been thinking more about this, and wondering if we should not
> only make the tupdesc available but rely more heavily on it than we
> do. Most of the C-coded functions do fairly substantial pushups to
> construct tupdescs that are just going to duplicate what
> nodeFunction
Joe Conway <[EMAIL PROTECTED]> writes:
>> I suppose that ExecMakeTableFunctionResult could be changed to *always*
>> pass ReturnSetInfo, even if it's not expecting the function to return
>> a set. That seems even less clean; but it would work, at least in the
>> current implementation.
> Hmmm. I
Joe Conway <[EMAIL PROTECTED]> writes:
> John Gray wrote:
>> Does this sound completely crazy?
> Not crazy at all. I asked the same question a few days ago:
> http://archives.postgresql.org/pgsql-hackers/2002-08/msg01914.php
I've been thinking more about this, and wondering if we should not
only
Tom Lane wrote:
> John Gray <[EMAIL PROTECTED]> writes:
>
>>Please correct me if I've got this wrong, but it appears from the SRF
>>API, that a SRF cannot readily refer to the TupleDesc to which it is
>>expected to conform (i.e. the TupleDesc derived from the FROM clause of
>>an original SELECT s
John Gray wrote:
> Please correct me if I've got this wrong, but it appears from the SRF
> API, that a SRF cannot readily refer to the TupleDesc to which it is
> expected to conform (i.e. the TupleDesc derived from the FROM clause of
> an original SELECT statement) because that is held in the exec
John Gray <[EMAIL PROTECTED]> writes:
> Please correct me if I've got this wrong, but it appears from the SRF
> API, that a SRF cannot readily refer to the TupleDesc to which it is
> expected to conform (i.e. the TupleDesc derived from the FROM clause of
> an original SELECT statement) because tha
> Please correct me if I've got this wrong, but it appears from the SRF
> API, that a SRF cannot readily refer to the TupleDesc to which it is
> expected to conform (i.e. the TupleDesc derived from the FROM
> clause of
> an original SELECT statement) because that is held in the
> executor state
Please correct me if I've got this wrong, but it appears from the SRF
API, that a SRF cannot readily refer to the TupleDesc to which it is
expected to conform (i.e. the TupleDesc derived from the FROM clause of
an original SELECT statement) because that is held in the executor state
and not copied
14 matches
Mail list logo
