Skip site navigation (1) Skip section navigation (2)

Re: 7.2.3?

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Justin Clift <justin(at)postgresql(dot)org>,Alvaro Herrera <alvherre(at)atentus(dot)com>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 7.2.3?
Date: 2002-09-29 17:05:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sun, 2002-09-29 at 19:28, Tom Lane wrote:
> Hannu Krosing <hannu(at)tm(dot)ee> writes:
> > The initial Postgres design had a notion of StorageManager's, which
> > should make this very easy indeed, if it had been kept working .
> But the storage manager interface was never built to hide issues like
> tuple representation --- storage managers just deal in raw pages.

I had an impression that SM was meant to be a little higher-level. IIRC
the original Berkeley Postgres had at one point a storage manager for
write-once storage on CDWr jukeboxes.

the README in src/backend/storage/smgr still contains mentions about
Sony jukebox drivers. also claims

Version 3 appeared in 1991 and added support for multiple storage
managers, an improved query executor and a rewritten rewrite rule
system. For the most part, releases since then have focused on
portability and reliability. 

> I doubt it would have helped in the least for anything we've been
> concerned about.

Yes, it seems that we do not have a SM in the semse I hoped.

Still, if we could use a clean SM interface over old page format, then
the tuple conversion could be done there.

That of course would need the storage manager to be aware of old/new
tuple structures ;(


In response to

pgsql-hackers by date

Next:From: Michael MeskesDate: 2002-09-29 17:20:32
Subject: Re: [ODBC] [ PostgreSQL integration Visual Basic, SQLProcedureColumns]
Previous:From: Alvaro HerreraDate: 2002-09-29 17:02:25
Subject: Re: DROP COLUMN misbehaviour with multiple inheritance

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group