From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Hadi Moshayedi <hadi(at)moshayedi(dot)net>, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: A question about code in DefineRelation() |
Date: | 2014-06-24 10:32:45 |
Message-ID: | 53A953CD.5020309@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 04/25/2014 04:39 PM, Hadi Moshayedi wrote:
>>
>> On second thought I noticed that that makes CREATE FOREIGN TABLE include
>> an OID column in newly-created foreign tables wrongly, when the
>> default_with_oids parameter is set to on. Please find attached a patch.
Yeah, that's a bug.
The interactions with pg_dump are interesting. If you have any tables
with OIDs in your database, pg_dump will output "set
default_with_oids=true" before creating those tables. And if you have
any foreign tables that end up being dumped after the table with OIDs,
it will also be created with "default_with_oids=true", and will end up
with OIDs.
Fortunately, nothing very bad happens if a foreign table has oids. It
will just be all-zeros if you select it.
Committed, and backpatched. 9.2 and 9.1 needed a slightly different
patch because the code has changed, but it was still straightforward.
> The fix makes sense to me, since in ALTER TABLE SET WITH OIDS we check that
> the relation is a table and not a foreign table:
>
> 3160 case AT_AddOids: /* SET WITH OIDS */
> 3161 ATSimplePermissions(rel, ATT_TABLE);
>
> So, I think we should be consistent between DefineRelation() and alter
> table.
Yeah, default_with_oids is definitely not supposed to affect foreign tables.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | geohas | 2014-06-24 10:49:17 | Hooks Docu - list of hooks |
Previous Message | David Rowley | 2014-06-24 10:32:21 | Re: Allowing NOT IN to use ANTI joins |