Re: Storage Location Patch Proposal for V7.3

From: mlw <markw(at)mohawksoft(dot)com>
To: Stefan Rindeskar <sr(at)globecom(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Storage Location Patch Proposal for V7.3
Date: 2001-11-08 13:52:22
Message-ID: 3BEA8E16.69197E95@mohawksoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stefan Rindeskar wrote:
>
> I just wanted to affirm that Tom's description sounds like av very good
> way to go.
>
> You get the best of two worlds with the possibility to tune servers and
> yet still
> very easy to manage. i.e. If you don't need it, don't mess with it and
> everything
> will work just fine.
> I don't either see any reason not to use the Oracle syntax since it is
> so widely used
> and it works very well for those of us that also work on Oracle (but in
> postgresql
> without the extent and storage clauses).
>

I absolutely agree with the concept of defining a location for data from within
the database. No argument.

The only two issues I can see are:

(1) Do not require the use of files as table spaces ala Oracle. That is an
admin nightmare. (Again, it would be cool, however, to be able to use table
space files so that PostgreSQL could have raw access as long as it is not a
requirement.) I don't think Tom is thinking about table space files, so I'm not
worried.

(2) I have a concern about expected behavior vs existing syntax. If PostgreSQL
uses "create tablespace" in such a way that an Oracle DBA will expect it to
work as Oracle does, it may cause a bit of confusion. We all know that
"confusion" between an open source solution and a "defacto" solution is used as
club.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-11-08 14:04:07 Re: 7.2 Beta2 bug report
Previous Message Kevin Jacobs 2001-11-08 13:39:30 Possible major bug in PlPython (plus some other ideas)