From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ugur Yilmaz <ugurlu2001(at)hotmail(dot)com> |
Cc: | "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Ynt: BUG #18793: PLpgSQL Function Returning Type of Table is not match for varchar(n) data type via Return Query |
Date: | 2025-02-09 23:19:27 |
Message-ID: | 2069593.1739143167@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Ugur Yilmaz <ugurlu2001(at)hotmail(dot)com> writes:
> Thank you for the explanations and information. Although I find your answers convincing; I still can't understand why I can't get the desired result from the Varchar(n) type, whose -max- length I explicitly specified in the "Returns Table" statement.
Yeah. There is about zero chance that we are going to rework that:
the decision that function argument and result types are identified
by type OID alone is ancient and deeply rooted. Even ignoring the
costs of changing a lot of code, there are semantic problems.
For example, should we allow both of these functions to exist
concurrently?
create function f(varchar(100)) returns ...;
create function f(varchar(200)) returns ...;
If so, which do we pick when we're uncertain about the length
of the argument value?
You could however make a reasonable case that we should not accept
"varchar(200)" in contexts where we're going to ignore the "(200)"
part. That's pretty ancient too, cf this comment in gram.y:
* We can catch over-specified arguments here if we want to,
* but for now better to silently swallow typmod, etc.
* - thomas 2000-03-22
I'm not sure whether rejecting such things would make more people
happy than it made unhappy.
In any case, there's a whole lot of history here and a lot of
reason to worry about backwards compatibility.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ugur Yilmaz | 2025-02-10 00:21:34 | Ynt: Ynt: BUG #18793: PLpgSQL Function Returning Type of Table is not match for varchar(n) data type via Return Query |
Previous Message | David G. Johnston | 2025-02-09 23:13:26 | Re: BUG #18793: PLpgSQL Function Returning Type of Table is not match for varchar(n) data type via Return Query |