From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | "jiangshan(dot)liu(at)tju(dot)edu(dot)cn" <jiangshan(dot)liu(at)tju(dot)edu(dot)cn>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #17869: Inconsistency between PL/pgSQL Function Parameter Handling and SQL Query Results |
Date: | 2023-03-26 15:19:49 |
Message-ID: | CAKFQuwZODJBFsmwABafXWhd6xCAKF8q_1EOE2xPZnPCDRcLYJw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Sunday, March 26, 2023, PG Bug reporting form <noreply(at)postgresql(dot)org>
wrote:
> The following bug has been logged on the website:
>
> Bug reference: 17869
> Logged by: Jiangshan Liu
> Email address: jiangshan(dot)liu(at)tju(dot)edu(dot)cn
> PostgreSQL version: 15.2
> Operating system: Ubuntu 18.04
> Description:
>
> However, when passing fixed-length character types as parameters in
> PL/pgSQL
> functions, the behavior seems to be different. The documentation states
> that
> parenthesized type modifiers are discarded by CREATE FUNCTION, meaning that
> CREATE FUNCTION foo (varchar(10)) is the same as CREATE FUNCTION foo
> (varchar) [2].
>
Yet more reason for why one should restrict themself to using the text data
type and forget about character as well as the length-specifying variants.
I’m doubting there is a bug here, rather a system limitation with a low
motivation to try and overcome.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-03-26 15:41:05 | Re: BUG #17869: Inconsistency between PL/pgSQL Function Parameter Handling and SQL Query Results |
Previous Message | PG Bug reporting form | 2023-03-26 13:21:37 | BUG #17869: Inconsistency between PL/pgSQL Function Parameter Handling and SQL Query Results |