pg_prepared_statements missing column
Hello Devs,
My buddy and I were running through the 15.1 docs today and found the
pg_prepared_statements view doesn't include the return_type column like it
says it should.
Here is the printout from /d pg_prepared_statements
View "pg_catalog.pg_prepared_statements" Column | Type | Collation |
Nullable | Default
-----------------+--------------------------+-----------+----------+---------
name | text | | | statement | text | | | prepare_time | timestamp with time
zone | | | parameter_types | regtype[] | | | from_sql | boolean | | |
generic_plans | bigint | | | custom_plans | bigint | | |
My version:
PostgreSQL 15.1 (Debian 15.1-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled
by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
Link to docs:
https://www.postgresql.org/docs/15/view-pg-prepared-statements.html
I'm not sure exactly what to make of it, but I wanted to submit a ticket.
Thanks for all your hard work!
-PG
Hi,
On Sat, Nov 12, 2022 at 11:37:34PM -0800, Peter Gigowski wrote:
My buddy and I were running through the 15.1 docs today and found the
pg_prepared_statements view doesn't include the return_type column like it
says it should.Here is the printout from /d pg_prepared_statements
View "pg_catalog.pg_prepared_statements" Column | Type | Collation |
Nullable | Default
-----------------+--------------------------+-----------+----------+---------
name | text | | | statement | text | | | prepare_time | timestamp with time
zone | | | parameter_types | regtype[] | | | from_sql | boolean | | |
generic_plans | bigint | | | custom_plans | bigint | | |My version:
PostgreSQL 15.1 (Debian 15.1-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled
by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bitLink to docs:
https://www.postgresql.org/docs/15/view-pg-prepared-statements.htmlI'm not sure exactly what to make of it, but I wanted to submit a ticket.
Indeed! It's a documentation bug. This was apparently an oversight
when packpatching 5766443695d (Bruce in Cc), as it introduced the result_types
column in the documentation in pg15 while the feature itself is only introduced
in pg16 (84ad713cf85).
On Sun, Nov 13, 2022 at 08:54:56PM +0800, Julien Rouhaud wrote:
Hi,
On Sat, Nov 12, 2022 at 11:37:34PM -0800, Peter Gigowski wrote:
My buddy and I were running through the 15.1 docs today and found the
pg_prepared_statements view doesn't include the return_type column like it
says it should.Here is the printout from /d pg_prepared_statements
View "pg_catalog.pg_prepared_statements" Column | Type | Collation |
Nullable | Default
-----------------+--------------------------+-----------+----------+---------
name | text | | | statement | text | | | prepare_time | timestamp with time
zone | | | parameter_types | regtype[] | | | from_sql | boolean | | |
generic_plans | bigint | | | custom_plans | bigint | | |My version:
PostgreSQL 15.1 (Debian 15.1-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled
by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bitLink to docs:
https://www.postgresql.org/docs/15/view-pg-prepared-statements.htmlI'm not sure exactly what to make of it, but I wanted to submit a ticket.
Indeed! It's a documentation bug. This was apparently an oversight
when packpatching 5766443695d (Bruce in Cc), as it introduced the result_types
column in the documentation in pg15 while the feature itself is only introduced
in pg16 (84ad713cf85).
I forgot to mention that I didn't check for any other new system view
introduced in pg16, between pg15 branching and 5766443695d. If there were they
whould likely be present in the pg15 version of the doc too.
Julien Rouhaud <rjuju123@gmail.com> writes:
On Sun, Nov 13, 2022 at 08:54:56PM +0800, Julien Rouhaud wrote:
Indeed! It's a documentation bug. This was apparently an oversight
when packpatching 5766443695d (Bruce in Cc),
Yeah, looks that way.
I forgot to mention that I didn't check for any other new system view
introduced in pg16, between pg15 branching and 5766443695d. If there were they
whould likely be present in the pg15 version of the doc too.
I did some diff'ing and couldn't identify any other discrepancies.
regards, tom lane