Re: Passing relation metadata to Exec routine - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Passing relation metadata to Exec routine
Date
Msg-id 3860875.1672091799@sss.pgh.pa.us
Whole thread Raw
In response to Passing relation metadata to Exec routine  (Nikita Malakhov <hukutoc@gmail.com>)
Responses Re: Passing relation metadata to Exec routine  (Nikita Malakhov <hukutoc@gmail.com>)
List pgsql-hackers
Nikita Malakhov <hukutoc@gmail.com> writes:
> While working on Pluggable TOAST [1] we found out that creation
> of new relation with CREATE TABLE AS... or CREATE TABLE LIKE -
> method
> static ObjectAddress create_ctas_internal(List *attrList, IntoClause *into)
> does not receive any metadata from columns or tables used in query
> (if any). It makes sense to pass not only column type and size, but
> all other metadata - like attoptions,base relation OID (and, maybe,
> reloptions), if the column from existing relation was used.

I am very, very skeptical of the premise here.

CREATE TABLE AS creates a table based on the output of a query.
That query could involve arbitrarily complex processing -- joins,
grouping, what-have-you.  I don't see how it makes sense to
consider the properties of the base table(s) in deciding how to
create the output table.  I certainly do not think it'd be sane for
that to behave differently depending on how complicated the query is.

As for CREATE TABLE LIKE, the point of that is to create a table
by copying a *specified* set of properties of a reference table.
I don't think letting an access method copy some other properties
behind the user's back is a great idea.  If you've got things that
it'd make sense to be able to inherit, let's discuss adding more
LIKE options to support that --- in which case the implementation
would presumably pass the data through in a non-back-door fashion.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Nikita Malakhov
Date:
Subject: Re: Pluggable toaster
Next
From: Tom Lane
Date:
Subject: Re: Error-safe user functions