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 =
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
+
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] =
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
triggers,
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] =
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:
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
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?)
So you mean
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:
... 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 compiles with
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
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 =
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 this
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 look
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:
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:
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
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
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 anonymous
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.
When represented as a Datum, the
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.
If I
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
22 matches
Mail list logo
