internal-accepting functions together this way. So what I propose is
that we allow STYPE = internal to be specified in CREATE AGGREGATE,
but only by superusers, who are trusted not to create security holes
anyway.
Does that mean that it's possible to use as STYPE pointer to complex C-structure
You can certainly screw yourself up by connecting some incompatible
internal-accepting functions together this way. So what I propose is
that we allow STYPE = internal to be specified in CREATE AGGREGATE,
but only by superusers, who are trusted not to create security holes
anyway.
Teodor Sigaev [EMAIL PROTECTED] writes:
Does that mean that it's possible to use as STYPE pointer to complex
C-structure
with internal pointers?
That's exactly what array_agg is doing. You have to be careful about
which context you keep the data in ...
regards, tom
Robert Haas [EMAIL PROTECTED] writes:
I would feel a lot better about it if we could invent some way of
distinguishing between different types of internal, based on what is
actually being pointed to.
Yeah, we discussed that awhile ago, but nothing's been done about it.
At this point I doubt it
On Fri, Nov 14, 2008 at 10:12 AM, Tom Lane [EMAIL PROTECTED] wrote:
Robert Haas [EMAIL PROTECTED] writes:
I would feel a lot better about it if we could invent some way of
distinguishing between different types of internal, based on what is
actually being pointed to.
Yeah, we discussed that
Robert Haas [EMAIL PROTECTED] writes:
On Fri, Nov 14, 2008 at 10:12 AM, Tom Lane [EMAIL PROTECTED] wrote:
Robert Haas [EMAIL PROTECTED] writes:
I would feel a lot better about it if we could invent some way of
distinguishing between different types of internal, based on what is
actually being
So I went off to convert contrib/intagg to a wrapper around the new core
functions, along this line:
CREATE OR REPLACE FUNCTION int_agg_state (internal, int4)
RETURNS internal
AS 'array_agg_transfn'
LANGUAGE INTERNAL;
CREATE OR REPLACE FUNCTION int_agg_final_array (internal)
RETURNS int4[]
AS
