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 <da...@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 <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers