From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] replace GrantObjectType with ObjectType |
Date: | 2018-01-19 20:11:18 |
Message-ID: | 7aaf2667-b3f0-bc1f-1be8-74eebda60d1e@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/17/18 23:52, Michael Paquier wrote:
> On Wed, Jan 17, 2018 at 05:23:25PM -0500, Peter Eisentraut wrote:
>> On 1/16/18 23:38, Michael Paquier wrote:
>>> + if (prop->objtype == OBJECT_TABLE)
>>> + /*
>>> + * If the property data says it's a table, dig a little deeper to get
>>> + * the real relation kind, so that callers can produce more precise
>>> + * error messages.
>>> + */
>>> + return relkind_get_objtype(get_rel_relkind(object_id));
>>> I guess that this is the price to pay as OBJECT_RELATION gets
>>> removed, but it seems to me that we want to keep the OBJECT_RELATION
>>> layer and look in depth at the relkind if is found...
>>
>> The problem I'm trying to solve is that keeping OBJECT_RELATION anywhere
>> means it has to be handled everywhere. This is the only place where
>> it's interesting, but it's only used to produce some error messages, so
>> I think it doesn't have to be terribly efficient and elegant.
>
> OK, I can live with that argument.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2018-01-19 20:33:38 | pgsql: Allow UPDATE to move rows between partitions. |
Previous Message | Tom Lane | 2018-01-19 19:54:25 | Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall |