| From: | Zhang Mingli <zmlpostgres(at)gmail(dot)com> |
|---|---|
| To: | Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Proposal to CREATE FOREIGN TABLE LIKE |
| Date: | 2025-02-06 12:13:47 |
| Message-ID: | 0663eec9-883d-4c25-ade4-58f227ece827@Spark |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Feb 6, 2025 at 18:31 +0800, Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, wrote:
>
> Ah, but our fine manual already says
>
> The LIKE clause can also be used to copy column definitions from views,
> foreign tables, or composite types. Inapplicable options (e.g.,
> INCLUDING INDEXES from a view) are ignored.
>
> so what you implemented seems to be okay from that POV.
Hi, Yeah,
Our current convention is to ignore any inapplicable options without throwing errors.
As you mentioned, we use bits to identify the options, which does add some complexity to the codes if we try to track the origin of the option bits.
--
Zhang Mingli
HashData
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nazir Bilal Yavuz | 2025-02-06 12:19:00 | Re: Show WAL write and fsync stats in pg_stat_io |
| Previous Message | Sutou Kouhei | 2025-02-06 12:06:31 | Re: Make COPY format extendable: Extract COPY TO format implementations |