Record returning function accept not matched columns declaration - Mailing list pgsql-bugs
From | Wetmore, Matthew (CTR) |
---|---|
Subject | Record returning function accept not matched columns declaration |
Date | |
Msg-id | 32d13003fc3c458a83f22c5024c2e295@evernorth.com Whole thread Raw |
In response to | Re: Record returning function accept not matched columns declaration (PetSerAl <petseral@gmail.com>) |
List | pgsql-bugs |
I had this issue as well. There is much inet talk about a bug in PGadmin in creating functions v cli, and how pgAdmin doesn't like some functions. I had to change my function to this method to get out of the error. The error wants you to have the columns in the function, not at SELECT statement. at least this was my issue, your mileage may vary. DROP FUNCTION IF EXISTS schema.function_name; CREATE OR REPLACE FUNCTION schema.function_name;( _typeahead character varying, _rolename character varying, _requiremisconductaccess character varying, _test1 character varying, _test2 character varying, _test3 character varying) RETURNS TABLE(col1 character varying, col2 character varying, col3 character varying) LANGUAGE 'plpgsql' COST 100 VOLATILE PARALLEL UNSAFE ROWS 1000 AS $BODY$ BEGIN -----Original Message----- From: PetSerAl <petseral@gmail.com> Sent: Thursday, February 29, 2024 2:02 PM To: David G. Johnston <david.g.johnston@gmail.com> Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-bugs@lists.postgresql.org Subject: [EXTERNAL] Re: Record returning function accept not matched columns declaration postgres=# with a(b) as (values (row(1,2,3))) postgres-# select * from a, coalesce(b); ERROR: a column definition list is required for functions returning "record" LINE 2: select * from a, coalesce(b); ^ postgres=# postgres=# with a(b) as (values (row(1,2,3))) postgres-# select * from a, nullif(b, null); ERROR: a column definition list is required for functions returning "record" LINE 2: select * from a, nullif(b, null); ^ postgres=# postgres=# with a(b) as (values (row(1,2,3))) postgres-# select * from a, unnest(array[b]); ERROR: a column definition list is required for functions returning "record" LINE 2: select * from a, unnest(array[b]); ^ postgres=# postgres=# with a(b) as (values (row(1,2,3))) postgres-# select * from a, json_populate_record(b, null); ERROR: a column definition list is required for functions returning "record" LINE 2: select * from a, json_populate_record(b, null); ^ postgres=# It seems PostgreSQL does not care about function being polymorphic, but only about return type being "record". It explicitlyrequire column definition list in all this cases. пт, 1 мар. 2024 г. в 00:32, David G. Johnston <david.g.johnston@gmail.com>: > > On Thu, Feb 29, 2024 at 1:11 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> >> "David G. Johnston" <david.g.johnston@gmail.com> writes: >> > On Thursday, February 29, 2024, PetSerAl <petseral@gmail.com> wrote: >> >> postgres=# with a(b) as (values (row(1,2,3))) postgres-# select * >> >> from a, coalesce(b) as c(d int,e int, f int) postgres-# union all >> >> postgres-# select * from a, nullif(b, null) as c(d int,e int, f >> >> int) postgres-# union all postgres-# select * from a, >> >> unnest(array[b]) as c(d int,e int, f int) postgres-# union all >> >> postgres-# select * from a, json_populate_record(b, null) as c(d >> >> int,e int, f int); --expect OK >> >> > My concern with all of this is accepting the specification of >> > column definitions for functions that don’t return the record pseudo-type. >> >> Hm? These cases all *do* return record, because that's what a.b is >> typed as. > > > I strongly dislike the seemingly overloaded terminology in this area. Namely I was trying to distinguish these two examplefunction signatures. > > json_populate_record ( base anyelement, from_json json ) → anyelement > jsonb_to_record ( jsonb ) → record > > Polymorphic functions do not require a column definition list. The non-polymorphic function signature does require thecolumn definition list. That we accept a column definition list in the polymorphic case is settled code but seems likeit led to this bug. > > David J.
pgsql-bugs by date: