Date: Thu, 12 Mar 2015 22:36:17 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Adam Brightwell <adam.brightwell@crunchydatasolutions.com>,
 Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>,
 Noah Misch <noah@leadboat.com>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: CATUPDATE confusion?
Message-ID: <20150313023617.GX29780@tamriel.snowman.net>
References: <20141227231829.GX3062@tamriel.snowman.net>
 <1952.1419722762@sss.pgh.pa.us>
 <20141227233150.GA2046947@tornado.leadboat.com>
 <CAKRt6CTrOf6w5sE5GDRQAJ+JQrfK4h8VM=jVCtiGC+mdFsmXGg@mail.gmail.com>
 <54FA8203.8080709@gmx.net> <4593.1425706263@sss.pgh.pa.us>
 <54FB0708.7070200@gmx.net>
 <20150307142441.GD29780@tamriel.snowman.net>
 <CAKRt6CRJVrSixLPfQQDh5k9rkviCxCv8CvFhr_wuB8HMwX-BDA@mail.gmail.com>
 <CA+TgmoaCea0wKzT0W4z7onHTVzogemP5Za+6wwWKsC4WJoin5A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="SWpKTRlZ6tbpMUDT"
Content-Disposition: inline
In-Reply-To: 
 <CA+TgmoaCea0wKzT0W4z7onHTVzogemP5Za+6wwWKsC4WJoin5A@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


--SWpKTRlZ6tbpMUDT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Sat, Mar 7, 2015 at 6:40 PM, Adam Brightwell
> <adam.brightwell@crunchydatasolutions.com> wrote:
> >> pg_shadow, pg_user and pg_group were added when role support was added,
> >> specifically for backwards compatibility.  I don't believe there was
> >> ever discussion about keeping them because filtering pg_roles based on
> >> rolcanlogin was too onerous.  That said, we already decided recently
> >> that we wanted to keep them updated to match the actual attributes
> >> available (note that the replication role attribute modified those
> >> views) and I think that makes sense on the removal side as well as the
> >> new-attribute side.
> >>
> >> I continue to feel that we really should officially deprecate those
> >> views as I don't think they're actually all that useful any more and
> >> maintaining them ends up bringing up all these questions, discussion,
> >> and ends up being largely busy-work if no one really uses them.
> >
> > Deprecation would certainly seem like an appropriate path for 'usecatup=
d'
> > (and the mentioned views).  Though, is there a 'formal' deprecation
> > policy/process that the community follows?  I certainly understand and
> > support giving client/dependent tools the time and opportunity to update
> > accordingly.  Therefore, I think having them read from 'rolsuper' for t=
he
> > time being would be ok, provided that they are actually removed at the =
next
> > possible opportunity.  Otherwise, I'd probably lean towards just removi=
ng
> > them now and getting it over with.
>=20
> Unless some popular tool like pgAdmin is using these views, I'd say we
> should just nuke them outright.  If it breaks somebody's installation,
> then they can always recreate the view on their particular system.
> That seems like an adequate workaround to me.

As near as I can tell, pgAdmin3 does still use pg_user (though I don't
think it uses pg_group or pg_shadow except when connected to an ancient
server) in some cases.  Where it is used, based on my quick review at
least, it looks like it'd be pretty easy to fix.

The rolcatupdate usage appears to all be associated with pg_authid
though, and the changes required to remove the places where it shows up
doesn't look particularly bad either.  There are no references to
usecatupdate.  Where there are references to 'use*', they'd have to also
be updated with the change to pg_user, naturally.

Looking at phppgadmin, there are quite a few more uses of pg_user there,
along with references to pg_group and even pg_shadow (for 8.0 and
earlier backends).  Amusingly, the only place 'catupdate' is referenced
there is in the Polish language file.  Updating phppgadmin to not
reference pg_user or the other views looks like it'd be a bit more work,
but not a huge effort either.

Basically, in my view at least, these programs are likely to continue to
use these backwards compatibility views until we either formally
deprecate them or (more likely) until we actually remove them and things
break.  As such, I'm not sure if this information really helps us make a
decision here.

	Thanks!

		Stephen

--SWpKTRlZ6tbpMUDT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJVAk0hAAoJEO1sijiDR2RVr9cP/36GFzLIYz0pmdOi9mPRGhuh
Pjhxb9+4hRDj4D+aTNgnLMorFj1fuU0gHspGyOmW2og5Y6b3AvqtqtrxzU6inZFY
WOnQVTErg7Ys6g22ZeAZRCNHqKv4Dsl30w1DoH8yfstfqO47SZFJ1Ly4P42Btolh
k0k8WtpvhiXcG27pLSO5Jsl5Hv8p1AzMdR7xI8Irmm4a6Uul/s1763+a3iCY1MT8
tYwory6zxzHXhCqyJX+klMjyX4cB7LBCLWlsTSPwEt009rwKwK3y1sh2G2yLfAC6
omcOAFt7Ned0Ee6QPpOgz2ujzGdLkMjDkhThVYhJYuE/lny/GbOcOQxLCuj+Uk3R
58N730VXwYyVPOGcpQmahTu35lGV1rXWIhB9lEjoBB+dNSojSbIDU+36nQunwKYP
zwHVtmbkbu20RaZT2deVGO+u8WaETAf6HGg4Tn260MKC81/o/swKcbsBUq0V/O1N
hvY6LxPenwlJ+RYQii8AAQm17OY2I/je0j47wowOvhcui/CZPb+zr3s1UcSzcZME
RNgYECk9CmCW3WqqMuzXFIn7jg6UrUMybJreKlfXJ3IlREAKWvROLem8m0j7GlU7
6AosHk1wpuj7wtYIuAAHEqqI3m0qYq2cpLlv/sZoHGpYDyHfsuCgdSU4yPEBjg+n
rDuUO/gG4mZss/BMwY8Z
=DBXi
-----END PGP SIGNATURE-----

--SWpKTRlZ6tbpMUDT--