Re: Add expressions to pg_restore_extended_stats()

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Tender Wang <tndrwang(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tomas Vondra <tomas(at)vondra(dot)me>
Subject: Re: Add expressions to pg_restore_extended_stats()
Date: 2026-03-04 22:05:55
Message-ID: CADkLM=eLuF7LzNKYnRFUWDDqS-eWYeP+jD2Gd+CES_GQQHT3uw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> 3. convert the record to jsonb, deleting the known annoying column keys
> (oids, timestamps, etc) and then set-differencing those.
> 4. do the views, but add in a regression check on the number of columns in
> the base table, with a comment that says "if this check ever fails, the new
> column(s) have to be added to the view above".
>
> For the reasons stated, I think it's down to options 3 and 4. Any
> preferences?
>

or

5. Generate the column list of the view (or set difference queries) with a
\gexec query that filters out the oids.

All of these things are sliiightly hacky, but if we settle on one pattern
that will allow us to use the pattern in multiple places and thus reduce
surprise to the reader.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2026-03-04 22:18:16 Re: Improve OAuth discovery logging
Previous Message Robert Haas 2026-03-04 22:04:23 Re: Consider low startup cost in add_partial_path