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:
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
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
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 =
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
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,
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
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
10 matches
Mail list logo
