On Fri, Jun 17, 2016 at 3:14 PM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
