Date: Sat, 12 Dec 2020 09:16:34 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
	Justin Pryzby <pryzby@telsasoft.com>,
	Alexey Kondratov <a.kondratov@postgrespro.ru>,
	Masahiko Sawada <masahiko.sawada@2ndquadrant.com>,
	Steve Singer <steve@ssinger.info>,
	pgsql-hackers@lists.postgresql.org,
	Robert Haas <robertmhaas@gmail.com>,
	Alexander Korotkov <a.korotkov@postgrespro.ru>,
	Masahiko Sawada <sawada.mshk@gmail.com>,
	Jose Luis Tallon <jltallon@adv-solutions.net>
Subject: Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on
 the fly
Message-ID: <X9QL4maC1b89F2my@paquier.xyz>
References: <a2e8a350-0228-6d83-e621-e57f24c54586@enterprisedb.com>
 <20201211202703.GA21264@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="JKXX2ph7LNevWQ16"
Content-Disposition: inline
In-Reply-To: <20201211202703.GA21264@alvherre.pgsql>
Precedence: bulk


--JKXX2ph7LNevWQ16
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Dec 11, 2020 at 05:27:03PM -0300, Alvaro Herrera wrote:
> By the way--  What did you think of the idea of explictly marking the
> types used for bitmasks using types bits32 and friends, instead of plain
> int, which is harder to spot?

Right, we could just do that while the area is changed.  It is worth
noting that all the REINDEX_REL_* handling could be brushed.  Another
point that has been raised on a recent thread by Peter was that people
preferred an hex style for the declarations rather than bit shifts.
What do you think?
--
Michael

--JKXX2ph7LNevWQ16
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAl/UC+IACgkQnvQgOdby
QH3NaRAAjemKRbjp7vqXBY9LbDUKAJYuNMbijbzKXjJc3QhAgz7+FQOt6kMgvNuC
GLvVyGqs6ogEGWGIwWXtyEX2WFfKtL/Zj+JFolyTNksM3NJV85P4Yr2VyhXHBrjV
krQlf/38Lopqtcu2pNrUfoqguybTpf7mnGFgDaZQk5hZTtSF64E6ZtsRkFMAaxkL
Vo2Ue6mTrZo5rtjV35R4RRn4iu8512xurAYs05qv0ZvGT0NxMfM44LSwtPTDdej3
p2rS2/I+N5TT0AGIe0934i6uKD5czonX7FhAnpo03ZVWsS3o+aN+Ty9UEuIWh28Y
Rodr3UBJVxetBg5NTXaq2JYDErM2zvLiWjpq8t8RCXRbD5l6Tnm8Z9SUaZ99jABl
a23GCzOGACrRudVFwLKbDAz3Q3nwahzznniwVOarL0xJakMTO9V4shEeKCtKUnha
QXBXJG+UENuCVnMfuECk+ACdYqmVbBq5oTeI16XhaarhCtVeVOqb9aGHlbZbL0wJ
CG86nC5sBjPSoZ9PXJzh12HDWrYLk4KfBE7n6gXD4QfBbS0QLA+xyQ8rvh3eMWUf
mVf567O4MIYGquplblHyWsBAZ6HI25Yk3eQffV2Gd+oXFgnOpOMXk47F2C+piSTr
YiE7QIU/Nm81rwwSmlYmJdSOebnOHYFF3m2bLXCpZcif8z76eIw=
=USGG
-----END PGP SIGNATURE-----

--JKXX2ph7LNevWQ16--