Tom Lane wrote:
If you really want the trigger API for PL/R to be indistinguishable from
the function-call API, then I think you will need to copy the passed
tuple and insert type information. This is more or less what
ExecEvalVar does now in the whole-tuple case (the critical code is
actually in
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
For triggers, I was previously building up the arguments thus:
slot = TupleDescGetSlot(tupdesc);
slot->val = trigdata->tg_trigtuple;
arg[7] = PointerGetDatum(slot);
I suppose now I should do this instead?
arg[7] = PointerGet
Joe Conway <[EMAIL PROTECTED]> writes:
>> Any ideas why the trigger tuple type isn't registered, or what I'm doing
>> wrong?
> A little more info on this. It appears that the tuple type is set to
> either 2249 (RECORDOID) or 0.
After further thought, we could possibly make it work for BEFORE
tr
Joe Conway <[EMAIL PROTECTED]> writes:
> For triggers, I was previously building up the arguments thus:
> slot = TupleDescGetSlot(tupdesc);
> slot->val = trigdata->tg_trigtuple;
> arg[7] = PointerGetDatum(slot);
> I suppose now I should do this instead?
> arg[7] = PointerGetDat
Joe Conway wrote:
Given the above changes, it's almost working now -- only problem left is
with triggers:
insert into foo values(11,'cat99',1.89);
+ ERROR: record type has not been registered
+ CONTEXT: In PL/R function rejectfoo
delete from foo;
+ ERROR: cache lookup failed for type 0
+ C
Tom Lane wrote:
No, it's a HeapTupleHeader pointer. You need to reconstruct a
HeapTuple on top of that to work with heap_getattr and most other
core backend routines.
Thanks.
For triggers, I was previously building up the arguments thus:
slot = TupleDescGetSlot(tupdesc);
slot->val = trig
Joe Conway <[EMAIL PROTECTED]> writes:
> Just for reference, what is arg[i] if it isn't a (TupleTableSlot *)
> anymore -- is it just a HeapTuple?
No, it's a HeapTupleHeader pointer. You need to reconstruct a HeapTuple
on top of that to work with heap_getattr and most other core backend
routines.
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
... The SRF API was for user defined functions, not
procedural languages anyway. I'll look at how the other procedural
languages handle tuple arguments.
It was a dozen-or-so-lines change in each of the PL languages AFAIR.
You will probably also
Joe Conway <[EMAIL PROTECTED]> writes:
> ... The SRF API was for user defined functions, not
> procedural languages anyway. I'll look at how the other procedural
> languages handle tuple arguments.
It was a dozen-or-so-lines change in each of the PL languages AFAIR.
You will probably also want to
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
/* for tuple args, convert to a one row data.frame */
TupleTableSlot *slot = (TupleTableSlot *) arg[i]; HeapTuple tuples
= slot->val; TupleDesc tupdesc = slot->ttc_tupleDescriptor;
Um. Well, the arg is not a TupleTableSlot * anymore, so thi
Joe Conway <[EMAIL PROTECTED]> writes:
> I still haven't had time to look closely, and well may have been doing
> something non-standard all along, but in any case this is the current
> failing code:
> /* for tuple args, convert to a one row data.frame */
> TupleTableSlot *slot = (Tupl
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Almost compatible. I found that, to my surprise, PL/R compiles with no
changes after your commit. However it no segfaults (as I expected) on
composite type arguments. Should be easy to fix though (I think, really
haven't looked at it hard ye
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> ... I believe that CVS tip is source-code-compatible with
>> existing SRFs, even though I adjusted all the ones in the distribution
>> to stop using the TupleTableSlot stuff.
> Almost compatible. I found that, to my surprise, PL/R compil
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
So you mean like an array, but with possibly mixed datatypes?
'{1 , "abc def", 2.3}'
Seems to make sense.
The unresolved question in my mind is how to represent NULL elements.
However, we have to solve that sooner or later for arrays too. Any
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> We will be able to make generic I/O routines for composite types,
>> comparable to those used now for arrays. Not sure what a convenient
>> external format would look like. (Possibly use the same conventions
>> as for a 1-D array?)
>
Tom Lane wrote:
We have a number of issues revolving around the fact that composite
types (row types) aren't first-class objects. I think it's past time
to fix that. Here are some notes about doing it. I am not sure all
these ideas are fully-baked ... comments appreciated.
[Sorry for the delay i
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Only named composite types, not RECORD, will be allowed to be used as
>> table column types.
> Interesting. I'm slightly curious to know if there's an external driver
> for this.
There's noplace to store a permanent record of an a
Tom,
> We have a number of issues revolving around the fact that composite types
> (row types) aren't first-class objects. I think it's past time to fix
> that. Here are some notes about doing it. I am not sure all these ideas
> are fully-baked ... comments appreciated.
I'll want to add to the
Tom Lane wrote:
We have a number of issues revolving around the fact that composite types
(row types) aren't first-class objects. I think it's past time to fix
that. Here are some notes about doing it. I am not sure all these ideas
are fully-baked ... comments appreciated.
[snip]
Only named
Greg Stark <[EMAIL PROTECTED]> writes:
> If I understand what you're talking about, you would be allowed to
> CREATE TYPE a composite type, like say, "address" and then use that as
> a datatype all over your database? And then if you find "address"
> needs a new field you can add it to the type and
Tom Lane <[EMAIL PROTECTED]> writes:
> We have a number of issues revolving around the fact that composite types
> (row types) aren't first-class objects. I think it's past time to fix
> that.
...
> Only named composite types, not RECORD, will be allowed to be used as
> table column types.
21 matches
Mail list logo
