Re: Proposal: Automatic partition creation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Proposal: Automatic partition creation
Date: 2020-07-06 16:10:37
Message-ID: 1378901.1594051837@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Jul 6, 2020 at 6:46 AM Anastasia Lubennikova
> <a(dot)lubennikova(at)postgrespro(dot)ru> wrote:
>> I am going to implement this via SPI, which allow to simplify checks and
>> calculations. Do you see any pitfalls in this approach?

> I don't really see why we need SPI here.

I would vote against any core facility that is implemented via SPI
queries. It is just too darn hard to control the semantics completely in
the face of fun stuff like varying search_path. Look at what a mess the
queries generated by the RI triggers are --- and they only have a very
small set of behaviors to worry about. I'm still only about 95% confident
they don't have security issues, too.

If you're using SPI to try to look up appropriate operators, I think
the chances of being vulnerable to security problems are 100%.

> I think the big problem here is identifying the operator to use. We
> have no way of identifying the "plus" or "minus" operator associated
> with a datatype; indeed, that constant doesn't exist.

We did indeed solve this in connection with window functions, cf
0a459cec9. I may be misunderstanding what the problem is here,
but I think trying to reuse that infrastructure might help.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thom Brown 2020-07-06 17:35:10 Multi-byte character case-folding
Previous Message Robert Haas 2020-07-06 15:45:09 Re: Proposal: Automatic partition creation