On Sat, Feb 5, 2011 at 10:56 AM, Tom Lane wrote:
> Robert Haas writes:
>> Err... wait. Actually, I think the right thing to do might be to
>> remove OCLASS_FOREIGN_TABLE altogether. I don't think it's actually
>> used for anything. For a foreign table, we use OCLASS_CLASS, just as
>> we do for
Robert Haas writes:
> Err... wait. Actually, I think the right thing to do might be to
> remove OCLASS_FOREIGN_TABLE altogether. I don't think it's actually
> used for anything. For a foreign table, we use OCLASS_CLASS, just as
> we do for indexes and sequences. I think that's just leftover cr
On Fri, Feb 4, 2011 at 2:46 PM, Robert Haas wrote:
> On Fri, Feb 4, 2011 at 2:44 PM, Tom Lane wrote:
>> While poking at the extensions patch I noticed that doDeletion() and
>> getObjectDescription() both seem to be missing cases for
>> OCLASS_FOREIGN_TABLE. Surely this is broken.
>
> I'll look i
On Fri, Feb 4, 2011 at 2:44 PM, Tom Lane wrote:
> While poking at the extensions patch I noticed that doDeletion() and
> getObjectDescription() both seem to be missing cases for
> OCLASS_FOREIGN_TABLE. Surely this is broken.
I'll look into fixing this.
--
Robert Haas
EnterpriseDB: http://www.e
While poking at the extensions patch I noticed that doDeletion() and
getObjectDescription() both seem to be missing cases for
OCLASS_FOREIGN_TABLE. Surely this is broken.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan