Christopher Kings-Lynne <[EMAIL PROTECTED]> 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 an SQL-invoked function is
an input parameter, one of which may be designated as the result
SQL parameter. The format 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-invoked function
that has a result SQL parameter. The result data type of a type-
preserving function is some 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
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
