From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parallelized polymorphic aggs, and aggtype vs aggoutputtype |
Date: | 2016-06-17 19:27:24 |
Message-ID: | CA+Tgmob10Fy0KJW5Bt7vx=JH6MjZd1riEqMHhEHX_q=VBvwxiA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jun 17, 2016 at 3:14 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> The concern I have is that you could stick it into an aggregate that isn't
> the one it's expecting to be used in, or into a slot in that aggregate
> that isn't deserialize(), and the run-time test can't detect either of
> those things. Now maybe this is locked down sufficiently by the fact
> that we don't let non-superusers create aggregates with transtype
> INTERNAL, but that seems pretty shaky to me given the number of moving
> parts in aggregates these days and the fact that we keep adding more.
Well, I'm not averse to changing it for more security, but "there
could be a bug there in somewhere" is a bit different from "the claim
in the comment there that it's okay if we check for aggregate context
is a joke".
>>> Not to mention that CREATE
>>> FUNCTION won't allow creation of such functions, so extensions are locked
>>> out of using this feature.
>
>> Oops.
>
> I think that means we *have* to change this.
Well, we don't *have* to change things for this reason, but it's
certainly not at all desirable for user-defined aggregates to be
locked out of this functionality. So I'm in favor of changing it.
>> I think we should break up internal into various kinds of internal
>> depending on what kind of a thing we've actually got a pointer to.
>
> Not a bad long-term project, but it's not happening in this cycle.
> I'm not very sure how we'd go about it anyway --- for examples
> like this, every new user-defined aggregate potentially wants its
> own flavor of "internal", so how do we manage that?
I think we'd want some way to easily spin up new internal-ish types.
CREATE TYPE myinternalthingy AS INTERNAL, or something like that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-06-17 19:35:25 | Re: Parallelized polymorphic aggs, and aggtype vs aggoutputtype |
Previous Message | Alvaro Herrera | 2016-06-17 19:26:45 | Re: Parallelized polymorphic aggs, and aggtype vs aggoutputtype |