Re: Storage Location Patch Proposal for V7.3 - Mailing list pgsql-hackers

From mlw
Subject Re: Storage Location Patch Proposal for V7.3
Date
Msg-id 3BEA8E16.69197E95@mohawksoft.com
Whole thread Raw
In response to Storage Location Patch Proposal for V7.3  ("Jim Buttafuoco" <jim@buttafuoco.net>)
List 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.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 7.2 Beta2 bug report
Next
From: Tom Lane
Date:
Subject: Re: 7.2 Beta2 bug report