wieck@debis.com (Jan Wieck) writes:
>> I don't really like the description of these functions as returning
>> something "OPAQUE", anyway, particularly when that is already being
>> (mis) used for user-defined type input/output functions. I wish
>> they were declared as returning something like "TUPLE".
> Yes, that would clearly separate trigger proc's from
> functions. And for unused arguments I would suggest VOID.
> But I expect (hope), you want to do this all during the fmgr
> redesign, not right now, no?
Yes, this ought to go along with fmgr changes, probably. But I'm still
unhappy about the idea of doing all these updates for long values to
varlena datatypes without doing the fmgr update at the same time.
I have been thinking some more about the schedule issue, and I still
think it's foolhardy to try to do the long-values change by Feb 1.
If you recall, that date was set on the assumption that we were only
going to clean up what we had before making the release, not insert
major new features.
If people are really excited about getting this done for the next
release, I propose that we forget all about Feb 1 and just say
"we'll release when this set of changes are done". We ought to deal
with all of these issues together:* support long values for varlena datatypes;* eliminate memory leaks for pass-by-ref
datatypes(both varlena and fixed-length);* rewrite fmgr interface to fix NULL and portability bugs.
If we don't do it that way, then not only will we ourselves be
having to visit each datatype module multiple times, but we will be
breaking user-added functions in two successive releases. Users
will not be happy about that. We should change these coding rules
that affect user datatypes *once*, and get it right the first time.
I'd personally prefer to see us put off all these issues till after
a Feb-1-beta release, but I fear I am fighting a losing battle there.
Let's at least be sane enough to recognize that we don't know quite
how long this will take.
regards, tom lane