Re: Extend ALTER DEFAULT PRIVILEGES for large objects

From: Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Extend ALTER DEFAULT PRIVILEGES for large objects
Date: 2024-04-26 08:54:06
Message-ID: 20240426175406.13e47ea3904de814afbfe496@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 24 Apr 2024 16:08:39 -0500
Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:

> On Tue, Apr 23, 2024 at 11:47:38PM -0400, Tom Lane wrote:
> > On the whole I find this proposed feature pretty unexciting
> > and dubiously worthy of the implementation/maintenance effort.
>
> I don't have any particularly strong feelings on $SUBJECT, but I'll admit
> I'd be much more interested in resolving any remaining reasons folks are
> using large objects over TOAST. I see a couple of reasons listed in the
> docs [0] that might be worth examining.
>
> [0] https://www.postgresql.org/docs/devel/lo-intro.html

If we could replace large objects with BYTEA in any use cases, large objects
would be completely obsolete. However, currently some users use large objects
in fact, so improvement in this feature seems beneficial for them.

Apart from that, extending TOAST to support more than 1GB data and
stream-style access seems a good challenge. I don't know if there was a
proposal for this in past. This is just a thought, for this purpose, we
will need a new type of varlena that can contains large size information,
and a new toast table schema that can store offset information or some way
to convert a offset to chunk_seq.

Regards,
Yugo Nagata

> --
> Nathan Bossart
> Amazon Web Services: https://aws.amazon.com

--
Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthias van de Meent 2024-04-26 10:23:45 Re: Extend ALTER DEFAULT PRIVILEGES for large objects
Previous Message Michael Banck 2024-04-26 08:43:44 Re: New GUC autovacuum_max_threshold ?