Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> Shouldn't you have the spec in one hand while designing this feature? :D
Actually, plpgsql generally pays more attention to Oracle than the spec ;-)
The truth though is that I'd missed that aspect of SQL99, and now that I
have read it I don't care to emulate it very closely. They seem to be
mixing up the simple business of input vs output parameters vs function
results with functions that are really methods of object classes:
An SQL-invoked function is an SQL-invoked routine whose invocation returns a value. Every parameter of
anSQL-invoked function is an input parameter, one of which may be designated as the result SQL parameter.
Theformat of an SQL-invoked function is specified by <SQL-invoked function> (see Subclause 11.49, "<SQL-invoked
routine>"). An SQL-invoked function can be a type-preserving function; a type-preserving function is an
SQL-invokedfunction that has a result SQL parameter. The result data type of a type- preserving function
issome subtype of the data type of its result SQL parameter.
The first part of that looks OK until you realize that they specified the
result parameter to be effectively INOUT not OUT ... and then it goes
downhill from there.
If we ever decide that we want to touch that stuff, we will still have
room to, because the spec actually thinks that a "result SQL parameter"
is one that has RESULT attached to its declaration; it's not simply a
matter of having a single OUT parameter. I don't think that this really
says what Gavin thought it did.
regards, tom lane
