Re: Complexity of contrib types

Bruce Momjian wrote:
>
> > Bruce Momjian <maillist@candle.pha.pa.us> wrote:
> > >
> > > Doing complex stuff like indexing with contrib stuff is tricky, and one
> > > reason we want to move stuff out of there as it becomes popular.  It is
> > > just too hard for someone not experienced with the code to implement.
> > > Add to this the fact that the oid at the time of contrib installation
> > > will change every time you install it, so it is even harder/impossible
> > > to automate.
> >
> > We should develop (or at least prominently promote _and_ document) some
> > kind of file/package format or tool (maybe like illustra datablades),
> > that would standardize the layout of contrib types.
> >
> > Also, the need to manually get oids is a real show-stopper.
> > A short-time solution would be to develop functions that return these
> > oids,
> > like get_proc_oid_for(proc_name,arg1_type,arg2_type,...).
>
> Can't they SELECT from pg_proc?

Making it a function would probably make the type-addition script
easier.

> >
> > 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.

Hannu