On Mon, Dec 23, 2013 at 7:45 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2013-12-20 13:22:07 +0100, Andres Freund wrote:
>> On 2013-12-20 07:12:01 -0500, Robert Haas wrote:
>> > I think the root of the problem is that nobody's very eager to add
>> > more hidden system catalog columns because each one bloats
>> > pg_attribute significantly.
>>
>> I think that part is actually solveable - there's no real need for them
>> to be real columns, present in pg_attribute, things could easily enough be
>> setup during parse analysis.
>
> I've spent some time yesterday hacking up a prototype for this. The
> amount of effort seems reasonable, although the attached patch certainly
> doesn't do all the neccessary things. The regression tests pass.
Well, I'm all in favor of de-bloating pg_attribute, but I don't
particularly like cooked_xmax. Even if it were better-named
(updatexid?), I'm still not sure I'd like it very much. And I
definitely think that getting rid of the pg_attribute entries ought to
be a separate patch from adding any new system columns we want to
have.
> In the prototype only oid keeps it's pg_attribute entry, everything else
> uses the static entries via
> SystemAttributeDefinition()/SystemAttributeByName(). We might want to
> remove oids as well, but it seems reasonable to continue allowing
> defining column permissions on it. And it's likely the attribute that's
> most likely ingrained deeply in user applications.
Seems fine to me.
>> The bigger problem I see is that adding
>> more useful columns will cause name clashes, which will probably
>> prohibit improvements in that direction.
>
> I wonder if we could solve that by naming new columns like
> "system:attribute" or similar. Not pretty, but maybe better than the
> alternatives.
If we're going to add a prefix, I think it should be one that doesn't
require quoting the identifier. In retrospect pg_xmin or _pg_xmin or
__pg_xmin would have been a better name than xmin.
But TBH, I'm kind of enamored of the function-based approach at the
moment. It just seems a lot more flexible. Adding a function is
nearly free and we can add as many as we need doing whatever we want,
and they can even go into contrib modules if we like it better that
way.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company