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