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@fetter.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.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
