Re: per-tablespace random_page_cost/seq_page_cost

On Tue, Nov 3, 2009 at 7:44 AM, Dimitri Fontaine <dfontaine(at)hi-media(dot)com> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> Le 1 nov. 2009 à 13:43, Greg Stark <gsstark(at)mit(dot)edu> a écrit :
>>>>
>>>> We could have a column for all booleans, a column for all integers,
>>>> etc. but that's not really any more normalized than having a single
>>>> column for all the types with a rule for how to marshal each value
>>>> type.
>>>
>>> Thé other day, on IRC, someone wanted a dynamic table accepting value in
>>> whichever column you name. That would probably mean having a special INSERT
>>> INTO which ALTER TABLE ... ADD COLUMN ... for you.
>>>
>>> Maybe INSERT INTO ... WITH ADD COLUMN OPTION;
>>>
>>> This sure looks suspicious, but the asking came from another product and it
>>> seems that could help here too. Oh and you get text columns I guess, by
>>> default...
>>
>> If you want to start a discussion about a topic that is completely
>> unrelated to this one, then please start a new thread.
>
> Auto adding a column on INSERT when it does not exists would help tools
> to add columns in there, to avoid having to follow EAV model.
>
> Maybe this property would be tied to the table rather than the INSERT,
> though, or maybe we'd be better without it at all. But it's related to
> the case at hand, yes.

I fail to see how. Even if such a feature were accepted, which
frankly I doubt it would be since I think you could code it up
yourself by using a function that takes an hstore and performs the
column additions for you as need be, I seriously doubt that it could
be made to work for system tables. And even if it could, it wouldn't
address my original point, which is that it would be faster to access
these properties by pulling them out of Form_pg_tablespace rather than
needing some more complicated system for extracting them - because you
certainly can't dynamically change the definition of a C struct that
is compiled into the executable dynamically at runtime.

Besides all that, what you are talking about here is a SQL-level
feature with SQL syntax. For possibly-obvious reasons, we don't
implement commands like ALTER TABLE by transforming them into SQL
queries that update the system catalogs. So even if someone did
implement this and it were accepted and it worked on system catalogs,
it still wouldn't be of any assistance to me in implementing ALTER
TABLESPACE ... SET. Can we stop now?

...Robert