Skip site navigation (1) Skip section navigation (2)

Re: security checks for largeobjects?

From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: David Fetter <david(at)fetter(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: security checks for largeobjects?
Date: 2009-06-23 04:24:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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 DasDate: 2009-06-23 06:05:02
Subject: PK not being restored
Previous:From: Andrew DunstanDate: 2009-06-23 04:11:16
Subject: Re: building without perl

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group