David Fetter wrote:
> On Tue, Jun 23, 2009 at 10:38:59AM +0900, KaiGai Kohei wrote:
>> David Fetter wrote:
>>> On Mon, Jun 22, 2009 at 11:31:45AM -0400, Tom Lane wrote:
>>>> David Fetter <david(at)fetter(dot)org> writes:
>>>>> On Mon, Jun 22, 2009 at 05:18:51PM +0300, Peter Eisentraut wrote:
>>>>>> MED is management of external data, whereas the large objects are
>>>>>> internal, no?
>>>>> It depends on your definition. The lo interface is pretty much to
>>>>> objects on the file system directly.
>>>> LO's are transaction-controlled, and they're not (readily)
>>>> accessible from outside the database. Seems rather completely
>>>> different from regular filesystem files.
>>> Not according to SQL/MED.
>>>> (In any case, there wasn't anything I liked about SQL/MED's ideas
>>>> about external files, so I'm not in favor of modeling LO management
>>>> after that.)
>>> Good point ;)
>> I would like to develop the feature independent from SQL/MED.
> If, as I suspect, SQL/MED does something that would collide with your
> feature, you're about to let yourself in for even more pain, as we
> tend to go with standard features over ones that would be unique to
> PostgreSQL, given the choice.
Since the largeobject is originally a unique feature in PostgreSQL,
I think it can be considered independently from the standard feature.
However, we have no fixed security design here. If you can provide more
preferable security design, could you suggest us?
I never disagree to improve the features.
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
In response to
pgsql-hackers by date
|Next:||From: Rajdeep Das||Date: 2009-06-23 06:05:02|
|Subject: PK not being restored|
|Previous:||From: Andrew Dunstan||Date: 2009-06-23 04:11:16|
|Subject: Re: building without perl|