Horton

Re: proposal: schema variables

Pavel Stehule <pavel.stehule@gmail.com>

View thread
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Erik Rijkers <er@xs4all.nl>, Michael Paquier <michael@paquier.xyz>, Zhihong Yu <zyu@yugabyte.com>, Amit Kapila <amit.kapila16@gmail.com>, DUVAL REMI <REMI.DUVAL@cheops.fr>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-07-22T08:55:30Z
Lists: pgsql-hackers, pgsql-performance

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Move WAL sequence code into its own file

  2. Add ExplainState argument to pg_plan_query() and planner().

  3. Don't include access/htup_details.h in executor/tuptable.h

  4. Refactor to avoid code duplication in transformPLAssignStmt.

  5. Avoid including commands/dbcommands.h in so many places

  6. Restrict psql meta-commands in plain-text dumps.

  7. Split func.sgml into more manageable pieces

  8. Fix squashing algorithm for query texts

  9. EXPLAIN: Always use two fractional digits for row counts.

  10. Preliminary refactoring of plpgsql expression construction.

  11. plpgsql: pure parser and reentrant scanner

  12. Add some sanity checks in executor for query ID reporting

  13. Fix misleading error message context

  14. Add macros for looping through a List without a ListCell.

po 22. 7. 2024 v 10:23 odesílatel Laurenz Albe <laurenz.albe@cybertec.at>
napsal:

> Thanks for the updated patch and the fixes!
>
> On Mon, 2024-07-22 at 08:37 +0200, Pavel Stehule wrote:
> > > > --- a/doc/src/sgml/ref/pg_restore.sgml
> > > > +++ b/doc/src/sgml/ref/pg_restore.sgml
> > >
> > > > +     <varlistentry>
> > > > +      <term><option>-A <replaceable
> class="parameter">schema_variable</replaceable></option></term>
> > > > +      <term><option>--variable=<replaceable
> class="parameter">schema_variable</replaceable></option></term>
> > > > +      <listitem>
> > > > +       <para>
> > > > +        Restore a named schema variable only.  Multiple schema
> variables may be specified with
> > > > +        multiple <option>-A</option> switches.
> > > > +       </para>
> > > > +      </listitem>
> > > > +     </varlistentry>
> > >
> > > Do we need that?  We have no such option for functions and other
> non-relations.
> >
> > It is designed to be consistent with others. pg_restore supports
> functions -P, triggers -T
> > >
> > > And if we really want such an option for "pg_restore", why not for
> "pg_dump"?
> > >
> >
> > I have no strong opinion about it, I think so it is consistent with
> other non-relations, but it is not important.
> >
> > I moved this feature to a separate patch. It can be committed optionaly
> or later.
> >
> > pg_restore has options -P, -T, and pg_dump does not have these options.
> These options (functionality) can
> > be implemented in pg_dump too, but unfortunately -T is used for
> different purposes (exclude table).
>
> Ah!  I didn't realize that -P and -T are the same.  So no objections,
> although I'm
> not sure if anyone will ever want to restore a single variable from a
> backup.
>

I wrote it mainly for completeness and symmetry. I can imagine only one use
case - possibility to offline trace the changes  of schema, but who knows.
The cost is just an occupation of 'A' char. Maybe it doesn't need a short
option, and a long option can be good enough.

Pavel



> Yours,
> Laurenz Albe
>