Re: Remove source code display from \df+? - Mailing list pgsql-hackers

From Isaac Morland
Subject Re: Remove source code display from \df+?
Date
Msg-id CAMsGm5f97iYDV9DF8sLjH2Lc+2cjis7OuYVEtGw+c21rGPUy2g@mail.gmail.com
Whole thread Raw
In response to Re: Remove source code display from \df+?  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: Remove source code display from \df+?
Re: Remove source code display from \df+?
List pgsql-hackers
On Sun, 22 Jan 2023 at 17:27, Justin Pryzby <pryzby@telsasoft.com> wrote:
On Sun, Jan 22, 2023 at 04:28:21PM -0500, Isaac Morland wrote:
> On Sun, 22 Jan 2023 at 15:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> But now I'm having a problem I don't understand: the CI are still failling,
> but not in the psql test. Instead, I get this:
>
> [20:11:17.624] +++ tap check in src/bin/pg_upgrade +++

You'll find the diff in the "artifacts", but not a separate "diff" file.
https://api.cirrus-ci.com/v1/artifact/task/6146418377752576/testrun/build/testrun/pg_upgrade/002_pg_upgrade/log/regress_log_002_pg_upgrade

 CREATE FUNCTION public.regress_psql_df_sql() RETURNS void
     LANGUAGE sql
     BEGIN ATOMIC
- SELECT NULL::text;
+ SELECT NULL::text AS text;
 END;

It's failing because after restoring the function, the column is named
"text" - maybe it's a bug.

OK, thanks. I'd say I've uncovered a bug related to pg_upgrade, unless I’m missing something. However, I've adjusted my patch so that nothing it creates is kept. This seems tidier even without the test failure.

Tom's earlier point was that neither the function nor its owner needs to
be preserved (as is done to exercise pg_dump/restore/upgrade - surely
functions are already tested).  Dropping it when you're done running \df
will avoid any possible issue with pg_upgrade.

Were you able to test with your own github account ?

I haven’t had a chance to try this. I must confess to being a bit confused by the distinction between running the CI tests and doing "make check"; ideally I would like to be able to run all the tests on my own machine without any external resources. But at the same time I don’t pretend to understand the full situation so I will try to use this when I get some time. 
Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: run pgindent on a regular basis / scripted manner
Next
From: Tom Lane
Date:
Subject: Re: run pgindent on a regular basis / scripted manner