pg_largeobjects - Mailing list pgsql-general

From James Sewell
Subject pg_largeobjects
Date
Msg-id CANkGpBvNjVfWY6dC-7thakvYJPTqk044AA-yvAfVnsm4bedaWQ@mail.gmail.com
Whole thread Raw
Responses Re: pg_largeobjects  (John R Pierce <pierce@hogranch.com>)
Re: pg_largeobjects  (Raghavendra <raghavendra.rao@enterprisedb.com>)
Re: pg_largeobjects  (Kevin Grittner <kgrittn@ymail.com>)
List pgsql-general
Hello all,

I have a table which makes use of pg_largeobjects. I am inserting rows into the table as user1. If I connect to the database as user2 I can SELECT data, but can not open the large object for reading (user1 can do this). I don't want to set lo_compat_privileges as then user3 (who can't SELECT from the services tables) would be able to read the large object.

I realise that pg_largeobjects is "partially obsolete" and I could solve the problem by just using TOAST, but this still seems incorrect.

As an aside, is there any reason to use pg_largeobjects if I am storing data under 1GB which doesn't require random reads any more? My impression is no?

SELECT * from services where payload = '51414';
-[ RECORD 1 ]--------------+------------------------
id                         | 2263
insert_date                | 2013-08-16 15:39:56.774
instance                   | createApp4
payload                    | 51414
update_date                | 2013-09-09 09:39:31.454
pe_service_transactions_id | 2262]

\lo_list
Large objects
-[ RECORD 1 ]--------
ID          | 51414
Owner       | user1
Description |

SELECT loread(lo_open(51414, 262144), 999999999);
ERROR:  permission denied for large object 51414


James Sewell,
PostgreSQL Team Lead / Solutions Architect
______________________________________
 

Level 2, 50 Queen St, Melbourne VIC 3000

P (03) 8370 8000  W www.lisasoft.com  F(03) 8370 8000
 


The contents of this email are confidential and may be subject to legal or professional privilege and copyright. No representation is made that this email is free of viruses or other defects. If you have received this communication in error, you may not copy or distribute any part of it or otherwise disclose its contents to anyone. Please advise the sender of your incorrect receipt of this correspondence.

pgsql-general by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: not aborting transactions on failed select
Next
From: Christoph Moench-Tegeder
Date:
Subject: Re: Need help with Inet type