Re: BUG #18793: PLpgSQL Function Returning Type of Table is not match for varchar(n) data type via Return Query
От | Tom Lane |
---|---|
Тема | Re: BUG #18793: PLpgSQL Function Returning Type of Table is not match for varchar(n) data type via Return Query |
Дата | |
Msg-id | 641679.1738684189@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #18793: PLpgSQL Function Returning Type of Table is not match for varchar(n) data type via Return Query (Laurenz Albe <laurenz.albe@cybertec.at>) |
Список | pgsql-bugs |
Laurenz Albe <laurenz.albe@cybertec.at> writes: > On Tue, 2025-02-04 at 12:43 +0000, PG Bug reporting form wrote: >> As far as I have determined, the Postgresql database engine somehow returns >> the varchar(n) - Fixed Length - data type as a "character varying" - >> indefinite length data type. > That is working asdesigned. Why is it a problem for you? Indeed. See the Notes section in [1]: The full SQL type syntax is allowed for declaring a function's arguments and return value. However, parenthesized type modifiers (e.g., the precision field for type numeric) are discarded by CREATE FUNCTION. Thus for example CREATE FUNCTION foo (varchar(10)) ... is exactly the same as CREATE FUNCTION foo (varchar) .... The RETURNS TABLE notation is just syntactic sugar for some output arguments, it doesn't change this aspect. Our general view of notations like varchar(10) is that the length limit is a kind of column constraint and is to be enforced against data "at rest" in a table. If you want something that's enforced on the fly during expression evaluation, you'll need to use a domain type with a CHECK constraint. regards, tom lane [1] https://www.postgresql.org/docs/current/sql-createfunction.html
В списке pgsql-bugs по дате отправления: