Tom Lane wrote:
> wieck@debis.com (Jan Wieck) writes:
> > One last point though. The comment says it's using lower case
> > name now to be callable from SQL, what it isn't because of
> > it's Opaque return type in pg_proc.
>
> > pgsql=> select update_pg_pwd();
> > ERROR: typeidTypeRelid: Invalid type - oid = 0
>
> > Is that a wanted (needed) capability or should I better
> > change the comment to reflect it's real nature?
>
> What would you expect the SELECT to produce here? I think the error
> message is pretty poor, but I can't really see OPAQUE functions being
> allowed in expression contexts...
Exactly that error message, you know as I know why it should
happen. What I wanted to know is, if there could be a reason
to make it callable via such a SELECT, to force it to do it's
action, or if that's just an old comment that's wrong now.
> 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?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #