Re: proposal: schema variables
Laurenz Albe <laurenz.albe@cybertec.at>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Move WAL sequence code into its own file
- a87987cafca6 19 (unreleased) cited
-
Add ExplainState argument to pg_plan_query() and planner().
- c83ac02ec730 19 (unreleased) cited
-
Don't include access/htup_details.h in executor/tuptable.h
- 1a8b5b11e48a 19 (unreleased) cited
-
Refactor to avoid code duplication in transformPLAssignStmt.
- b0fb2c6aa5a4 19 (unreleased) cited
-
Avoid including commands/dbcommands.h in so many places
- 325fc0ab14d1 19 (unreleased) cited
-
Restrict psql meta-commands in plain-text dumps.
- 71ea0d679543 19 (unreleased) cited
-
Split func.sgml into more manageable pieces
- 4e23c9ef65ac 19 (unreleased) cited
-
Fix squashing algorithm for query texts
- 0f65f3eec478 18.0 cited
-
EXPLAIN: Always use two fractional digits for row counts.
- 95dbd827f2ed 18.0 cited
-
Preliminary refactoring of plpgsql expression construction.
- a654af21ae52 18.0 cited
-
plpgsql: pure parser and reentrant scanner
- 7b27f5fd36cb 18.0 cited
-
Add some sanity checks in executor for query ID reporting
- 24f520594809 18.0 cited
-
Fix misleading error message context
- 4af123ad45bd 18.0 cited
-
Add macros for looping through a List without a ListCell.
- 14dd0f27d7cd 17.0 cited
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. Yours, Laurenz Albe