> At 12:27 PM 6/21/00 +1000, Chris Bitmead wrote:
> >Tom Lane wrote:
> >> Some unhappiness was raised about
> >> depending on symlinks for this function, but I didn't hear one single
> >> concrete reason not to do it, nor an alternative design.
> >
> >Are symlinks portable?
>
> In today's world? Yeah, I think so.
>
> My only unhappiness has hinged around the possibility that a new
> storage scheme might temp folks to toss aside the sgmr abstraction,
> or weaken it.
>
> It doesn't appear that this will happen.
>
> Given an adequate sgmr abstraction, it doesn't really matter what
> low-level model is adopted in some sense (i.e. other models might
> become available, the implemented model might get replaced, etc -
> without breaking backends).
>
> Obviously we'll all be using the default model for some time, maybe
> forever, but if mistakes are made maintaining the smgr abstraction
> means that replacements are possible. Or kinky substitutes like
> working with DAFS.
The symlink solution where the actual symlink location is not stored
in the database is certainly abstract. We store that info in the file
system, which is where it belongs. We only query the symlink location
when we need it for database location dumping.
-- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026