Re: Complexity of contrib types
От | Bruce Momjian |
---|---|
Тема | Re: Complexity of contrib types |
Дата | |
Msg-id | 199807211547.LAA29661@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Complexity of contrib types (Hannu Krosing <hannu@trust.ee>) |
Список | pgsql-hackers |
> > Can't they SELECT from pg_proc? > > Making it a function would probably make the type-addition script > easier. I guess, but much less flexible. > > > > > > > The real solution would of course be extending the (Postgre)SQL language > > > to find the OIDs automatically, like Oracle currently does for its > > > COMMENT > > > statement, an equivalent of which could be used in PostgreSQL to insert > > > values in pg_description on the fly. > > > > We return oid's as part of an INSERT. Is that what you meant? > > It is very hard (probably impossible) to use them from a psql script. > > If I remember the syntax right (have'nt used Oracle for >=2 years), > I could do: > > COMMENT "this is a nice table" ON TABLE nice_table; > COMMENT "this is an unnecessary field from a nice table" > ON FIELD nice_table.unnecessary_field; > > Of course, to fully support it we would need a much improved foreign > key support, so that we could set the ON DELETE CASCADE for the > commented on tables, and do it so that the foreign key can references > _any_ table ;). > > If we could manage that, we could really call PostgreSQL an OO database. We could create a function that returned the previously inserted oid, and use that in the next query. insert into test values (4); update test3 set val = lastoid(); Just remember the lastoid inserted in the backend code. Seems easy. Do you want it added to the TODO list. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
В списке pgsql-hackers по дате отправления: