From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Fetter <david(at)fetter(dot)org>, Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: CREATE FOREIGN TABLE ( ... LIKE ... ) |
Date: | 2014-04-08 00:26:30 |
Message-ID: | CAB7nPqRX-6P5+iy-mktnP_Mk0_ThVcCxseYcp1C+QFvSEgL8Nw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 8, 2014 at 5:24 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2014-04-05 11:46:16 -0400, Tom Lane wrote:
>> ISTM this is because the proposed feature is wrongheaded. The basic
>> concept of CREATE TABLE LIKE is that you're copying properties from
>> another object of the same type. You might or might not want every
>> property, but there's no question of whether you *could* copy every
>> property. In contrast, what this is proposing to do is copy properties
>> from (what might be) a plain table to a foreign table, and those things
>> aren't even remotely the same kind of object.
>>
>> It would make sense to me to restrict LIKE to copy from another foreign
>> table, and then there would be a different set of INCLUDING/EXCLUDING
>> options that would be relevant (options yes, indexes no, for example).
>
> I actually think it's quite useful to create a foreign table that's the
> same shape as a local table. And the patches approach of refusing to
> copy thinks that aren't supported sounds sane to me.
This could be improved as well: it would be useful to be able to copy
the column options of another foreign table.
> Consider e.g. moving off older partitioned data off to an archiving
> server. New local partitions are often created using CREATE TABLE LIKE,
> but that's not possible for the foreign ones.
Definitely a use case.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-04-08 01:47:38 | Re: Why is it not sane to pass ExecStoreTuple(shouldFree=true) for tuples point into buffers |
Previous Message | Peter Geoghegan | 2014-04-07 23:32:02 | Re: B-Tree support function number 3 (strxfrm() optimization) |