Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sVoq6-00BnSl-QN for pgsql-hackers@arkaria.postgresql.org; Mon, 22 Jul 2024 08:56:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sVoq4-00GarL-4V for pgsql-hackers@arkaria.postgresql.org; Mon, 22 Jul 2024 08:56:12 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sVoq3-00GarD-PY for pgsql-hackers@lists.postgresql.org; Mon, 22 Jul 2024 08:56:12 +0000 Received: from mail-yb1-xb36.google.com ([2607:f8b0:4864:20::b36]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sVoq1-000qLp-UH for pgsql-hackers@lists.postgresql.org; Mon, 22 Jul 2024 08:56:11 +0000 Received: by mail-yb1-xb36.google.com with SMTP id 3f1490d57ef6-e0875778facso1619871276.3 for ; Mon, 22 Jul 2024 01:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721638568; x=1722243368; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vrx/7n8rvb0AbxYIJuAZ8eWF7erV/csgOaM5sC8i+HU=; b=RoPhgK2dyQ80FqunR038GQkutQoq+xAHDy0w4iis3owWrJsrEx/0MEAidQ/i15dH6v fC0wFWLb4cfiLt6ETN2FyUxmZpgeEhTCicnN58aRNsk8q4qEAw4PLKesHUIg4BJ92X4Z Q1YhKYBgPlhEOx08Hfjnftzi7KmX1JKsIPBibdZ9TewX6QCmaWUl6f8wm+1gL3TJmhL5 CqIt49o3ok6LhiIb6JnC1Zp870s8pUDvvf60+RCpD1vWeY7Jq7c2NL5Wy8Jv1V3kJVdF SEVEcLnV5+ViJLdqhyLyE/HCJaNfFYXqpMwNjO9AN5VNFtDeQ8SA7b6DWFF6drbAdi1C TWTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721638568; x=1722243368; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vrx/7n8rvb0AbxYIJuAZ8eWF7erV/csgOaM5sC8i+HU=; b=rN3YKi1DU8JNWF03Aab7rWYtxEZXrtopD2aPOKZM7eTJNNo7N9bM6RbQ5Y9v2qXRgw u+AzETJcF3aWBT8T3fcqhrQKvq3dpx0RD1koGer+/F0/WX0ptIJWJkKrh9KfpL57I/91 /p8s62KF310YdpbLK5vcuQLV7w9j1XewqezwQTD8CKcYNIo0w1vVLVpln/sy4AbbRF9y vd/c4ctqisRHKHnhS2obRlBEZqgp7IntKLeG7XYqQfErjQiRNmW9AszU0ckvQ8qGGReq s3ForAHNelHzmCfCSRkyGWH+ApMzfwXp7/1zZxyPTvZUe9nSq/1/Akq1OY1YDs+E0F0A EvOQ== X-Forwarded-Encrypted: i=1; AJvYcCW+MKj8QBK+8/pmDQWlQTsVFZZdLJSLeTu+LY6ODYj1UVf6MhEcwIhq9b0LGUZl3UUQ5LonKowaldNVFYEJ0MrzMxuQqgDY+smYpQwUkqAypo5l X-Gm-Message-State: AOJu0Yy/07pVym08kRob6fXb+38fRi5wOTVvzyPU4y0Qgweo923uMJKr w/mM+54+y/DbPJplmD2CXaYy17I0pDwM718CAlClL3SRec2s67DILz8qGxD/CqJqn8jPB6CPJTr vLkN29NPMotackqYlArHaOnsq5KE= X-Google-Smtp-Source: AGHT+IHWlY9TBgloFUEH5NuJ2OV/Vdyl8vmqCsYE3C3J5ixoS0MaVCsmDKHSDascIi04jp8aRtRX2W7m5GsVJk6S/7g= X-Received: by 2002:a05:6902:20c5:b0:e06:fe1a:ffcc with SMTP id 3f1490d57ef6-e087b95efe0mr5765967276.53.1721638567953; Mon, 22 Jul 2024 01:56:07 -0700 (PDT) MIME-Version: 1.0 References: <20200924035637.GF28585@paquier.xyz> <20201001033824.GC8130@paquier.xyz> <51a9a68e8a998d04df17417d45c1dbd4@xs4all.nl> <89817942c99da01cd5e7850fe418436b@xs4all.nl> <56ca532c37eb0b540961f74a7bd5db39@xs4all.nl> <8181bd3abc647bdae5a4f78e71e62478a98c75f4.camel@cybertec.at> <890e1f8bf8eb45af17c892016674c752cb3ab8dc.camel@cybertec.at> In-Reply-To: <890e1f8bf8eb45af17c892016674c752cb3ab8dc.camel@cybertec.at> From: Pavel Stehule Date: Mon, 22 Jul 2024 10:55:30 +0200 Message-ID: Subject: Re: proposal: schema variables To: Laurenz Albe Cc: Erik Rijkers , Michael Paquier , Zhihong Yu , Amit Kapila , DUVAL REMI , PostgreSQL Hackers Content-Type: multipart/alternative; boundary="000000000000464ddc061dd2379b" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000464ddc061dd2379b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable po 22. 7. 2024 v 10:23 odes=C3=ADlatel Laurenz Albe 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 > > > > > > > + > > > > + > > > > + > > > > + > > > > + > > > > + Restore a named schema variable only. Multiple schema > variables may be specified with > > > > + multiple switches. > > > > + > > > > + > > > > + > > > > > > 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 > --000000000000464ddc061dd2379b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
po 22. 7. 2024 v=C2=A010:23 odes=C3= =ADlatel Laurenz Albe <laure= nz.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
> >
> > > +=C2=A0 =C2=A0 =C2=A0<varlistentry>
> > > +=C2=A0 =C2=A0 =C2=A0 <term><option>-A <repla= ceable class=3D"parameter">schema_variable</replaceable>= </option></term>
> > > +=C2=A0 =C2=A0 =C2=A0 <term><option>--variable= =3D<replaceable class=3D"parameter">schema_variable</rep= laceable></option></term>
> > > +=C2=A0 =C2=A0 =C2=A0 <listitem>
> > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0<para>
> > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 Restore a named schema variable= only.=C2=A0 Multiple schema variables may be specified with
> > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 multiple <option>-A</o= ption> switches.
> > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0</para>
> > > +=C2=A0 =C2=A0 =C2=A0 </listitem>
> > > +=C2=A0 =C2=A0 =C2=A0</varlistentry>
> >
> > Do we need that?=C2=A0 We have no such option for functions and o= ther non-relations.
>
> It is designed to be consistent with others. pg_restore supports funct= ions -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 ot= her non-relations, but it is not important.
>
> I moved this feature to a separate patch. It can be committed optional= y 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 differ= ent purposes (exclude table).

Ah!=C2=A0 I didn't realize that -P and -T are the same.=C2=A0 So no obj= ections, although I'm
not sure if anyone will ever want to restore a single variable from a backu= p.

I wrote it mainly for completeness a= nd symmetry. I can imagine only one use case - possibility to offline trace= the changes=C2=A0 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
--000000000000464ddc061dd2379b--