I wonder if there's any use for an allow_large_objects = true/false GUC
parameter?

It'd be nice to be able to switch it off as part of site policy so that
the security holes in it aren't able to be exposed, plus you can
guarantee as the site admin that pg_dumpall will produce a complete
dump. Also, you can guarantee that you don't have to worry about
vacuumlo or anything.

This might come in handy one day when we want to deprecate large objects
perhaps.

Chris

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> I wonder if there's any use for an allow_large_objects = true/false GUC
> parameter?

> It'd be nice to be able to switch it off as part of site policy so that
> the security holes in it aren't able to be exposed, plus you can
> guarantee as the site admin that pg_dumpall will produce a complete
> dump.

Security holes? Explain yourself please.

As for the latter point, ISTM the todo item is "fix pg_dumpall" more
than "eliminate large objects". Certainly the fix isn't easy, but
that isn't an argument to cut and run.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

> Security holes? Explain yourself please.

No ownership, and no permissions...

> As for the latter point, ISTM the todo item is "fix pg_dumpall" more
> than "eliminate large objects". Certainly the fix isn't easy, but
> that isn't an argument to cut and run.

I did have a plan to do this for 8.1, but so far it's not looking like
I'll have the time...

Chris

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster