Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine
От | Merlin Moncure |
---|---|
Тема | Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine |
Дата | |
Msg-id | b42b73150812100623t54405b1eif18e4d6aab5c8c7c@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: ALTER composite type does not work, but ALTER TABLE
which ROWTYPE is used as a type - works fine
Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine |
Список | pgsql-hackers |
On Wed, Dec 10, 2008 at 9:05 AM, Alvaro Herrera <alvherre@commandprompt.com> wrote: > Merlin Moncure escribió: >> >> Bruce Momjian <bruce@momjian.us> http://momjian.us >> >> OK, so what should the TODO item be? >> On Wed, Dec 10, 2008 at 7:44 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> > Allow ALTER TYPE to add, rename, change the type of, and drop columns? >> >> That's probably the consensus view. Personally, I think creating >> composite types through 'create type as' was a mistake...we probably >> should have gone through create table instead with some special syntax >> for storage-less tables aka composite types. > > I disagree that CREATE TABLE should be (or should have been) used to > create types. Someday we might need to expand the work we do for that > case in a different direction than tables, and we would be stuck. But, tables _are_ types, particularly in relational parlance. In fact, postgresql's older, more relational terms (tuples and such) are coming from that perspective, although I admit that's mostly irrelevant now. I think we are more stuck now, having to re-implement many things alter table does in 'alter type (as)???'. It's a mess. What if we want to add check constraints to composite types? > Also, for tables we create files, we generate statistics, we compute > relfrozenxid, we call vacuum on, and so on and so forth. We do none of > these things on types. Those things are what come with 'storage' so if you are defining a type with no storage mechanism you could possibly skip those things. > In fact, types are not in pg_class at all. incorrect!! composite types are in pg_class (relkind='c'). That actually knida confirms what I'm saying, composite types were added in a confusing overlay over the 'create type' command, which is something completely different. create type means two completely different things depending on a minor grammar change...gah! :-) I still stand by by statement...create table should have allowed you to create a composite type as we do it with create type as today...and (perhaps) storage (relfrozenxid etc.) could be added or removed with alter table. merlin
В списке pgsql-hackers по дате отправления: