Ynt: Ynt: BUG #18793: PLpgSQL Function Returning Type of Table is not match for varchar(n) data type via Return Query

From: Ugur Yilmaz <ugurlu2001(at)hotmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Ynt: Ynt: BUG #18793: PLpgSQL Function Returning Type of Table is not match for varchar(n) data type via Return Query
Date: 2025-02-10 00:21:34
Message-ID: DU0PR10MB71425233264A7687CB729D6FC0F22@DU0PR10MB7142.EURPRD10.PROD.OUTLOOK.COM
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

As a result of the current answers, I think it would be logical to close this "bug request" due to "past compatibility" concerns.

However, in the future, I can suggest that this issue "somehow" remains with the "Updatable Flag". At the end of the day, this situation was a "Surprise" for me in terms of my respect for Postgresql and the time I spent on it for "Application Development" purposes.

Since version 9.1, this is the second most critical problem I have encountered with Postgresql (only for me) (the first was the Turkish character incompatibility experienced on a global scale - Postgresql service not working with Cumulative Windows Update). I can ignore this for now since I can get around the problem with alternative solutions.

Thanks for your answers and the time you spent on your answers.

Best wishes.

Ugur YILMAZ
________________________________
Gönderen: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Gönderildi: 10 Şubat 2025 Pazartesi 02:19
Kime: Ugur Yilmaz <ugurlu2001(at)hotmail(dot)com>
Bilgi: pgsql-bugs(at)lists(dot)postgresql(dot)org <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Konu: Re: Ynt: BUG #18793: PLpgSQL Function Returning Type of Table is not match for varchar(n) data type via Return Query

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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2025-02-10 00:55:01 Re: BUG #18793: PLpgSQL Function Returning Type of Table is not match for varchar(n) data type via Return Query
Previous Message Tom Lane 2025-02-09 23:19:27 Re: Ynt: BUG #18793: PLpgSQL Function Returning Type of Table is not match for varchar(n) data type via Return Query