On 2015-03-02 16:42:35 -0500, Robert Haas wrote:
> On Tue, Feb 3, 2015 at 10:12 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Two reasons this isn't terribly compelling are (1) it's creating a
> > join in a place where the planner can't possibly see it and optimize
> > it, and (2) you risk MVCC anomalies because the reg* output routines
> > would not be using the same snapshot as the calling query.
> >
> > We already have problem (2) with the existing reg* functions so I'm
> > not that excited about doubling down on the concept.
>
> I think I agree. I mean, I agree that this notation is more
> convenient, but I don't really want to add a whole new slough of types
> --- these will certainly not be the only ones we want once we go down
> this path --- to the default install just for notational convenience.
> It's arguable, of course, but I guess I'm going to vote against this
> patch.
That's a justifyable position. I don't think there are other catalogs
referenced as pervasively in the catalog though.
There's one additional point: Using reg* types in the catalog tables
themselves can make them *much* easier to read. I personally do look at
the catalogs a awful lot, and seing names instead of oids makes it much
easier. And adding regtype/role would allow to cover nearly all types
containing oids.
Incidentally I've started working on a replacement for the bki DATA
stuff
(http://archives.postgresql.org/message-id/20150220234142.GH12653%40awork2.anarazel.de)
and of the things that makes the biggest difference in editing based on
my experience is not to have to list endless columns of oids that you
have to figure out by hand. Replacing e.g. prorettype/proallargtypes
oids by their names made it much, much easier to read. And my initial
implementation simply supports that based on the column type... So
adding regnamespace/regrole actually might help there.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services