Thread: Re: [ODBC] New driver options in 7.01.0007

> -----Original Message-----
> From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> Sent: 24 September 2001 08:48
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org; 'pgadmin-hackers@postgresql.org'
> Subject: Re: [ODBC] New driver options in 7.01.0007
>
>
> Dave Page wrote:
> >
> > > -----Original Message-----
> > > From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> > > Sent: 24 September 2001 01:48
> > > To: Johann Zuschlag
> > > Cc: pgsql-odbc@postgresql.org
> > > Subject: Re: [ODBC] New driver options in 7.01.0007
> > >
> > >
> > > My work about updatable cursors may lose the
> > > meaing by a backend's change. My plan depends
> > > on the combination of TID and OID but OIDs would
> > > be optional in 7.2.
> >
> > What?? OIDs optional?? That will *seriously* break pgAdmin at first
> > thought. If anyone can give more info on this it would be
> appreciated
> > as I can't seem to get to the list archives at the moment.
>
> The following system tables don't have OIDs.
>
>     relname     | relhasoids
> ----------------+------------
>  pg_attribute   | f
>  pg_group       | f
>  pg_inherits    | f
>  pg_index       | f
>  pg_amop        | f
>  pg_amproc      | f
>  pg_largeobject | f
>  pg_listener    | f
>  pg_shadow      | f
>  pg_attrdef     | f
>  pg_description | f
>  pg_relcheck    | f
>  pg_statistic   | f

Thanks Hiroshi. That's less of a problem than I first imagined, but it will
probably still break pgAdmin completely.

I assume there's a good reason for removing them?

Regards, Dave.

Dave Page wrote:

> > > What?? OIDs optional?? That will *seriously* break pgAdmin at first
> > > thought. If anyone can give more info on this it would be
> > appreciated
> > > as I can't seem to get to the list archives at the moment.
> >
> > The following system tables don't have OIDs.
> >
> >     relname     | relhasoids
> > ----------------+------------
> >  pg_attribute   | f
> >  pg_group       | f
> >  pg_inherits    | f
> >  pg_index       | f
> >  pg_amop        | f
> >  pg_amproc      | f
> >  pg_largeobject | f
> >  pg_listener    | f
> >  pg_shadow      | f
> >  pg_attrdef     | f
> >  pg_description | f
> >  pg_relcheck    | f
> >  pg_statistic   | f
>
> Thanks Hiroshi. That's less of a problem than I first imagined, but it will
> probably still break pgAdmin completely.
>
> I assume there's a good reason for removing them?

PostgreSQL doesn't need/use their OIDs internally.
For example (attrelid, attnum) identifies the tuple
in pg_attribute properly. In addition they have
no index on thier OIDs and so the access to the
table via the OIDs aren't effective if the tables
are pretty large.

regards,
Hiroshi Inoue

> -----Original Message-----
> From: Dave Page
> > >
> > > What?? OIDs optional?? That will *seriously* break pgAdmin at first
> > > thought. If anyone can give more info on this it would be
> > appreciated
> > > as I can't seem to get to the list archives at the moment.
> >
> > The following system tables don't have OIDs.
> >
> >     relname     | relhasoids
> > ----------------+------------
> >  pg_attribute   | f
> >  pg_group       | f
> >  pg_inherits    | f
> >  pg_index       | f
> >  pg_amop        | f
> >  pg_amproc      | f
> >  pg_largeobject | f
> >  pg_listener    | f
> >  pg_shadow      | f
> >  pg_attrdef     | f
> >  pg_description | f
> >  pg_relcheck    | f
> >  pg_statistic   | f
>
> Thanks Hiroshi. That's less of a problem than I first imagined,
> but it will
> probably still break pgAdmin completely.

Note that restoring from pg_dump would abort if there
are pgAdmin tables.

regards,
Hiroshi Inoue