| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Stephen Frost <sfrost(at)snowman(dot)net>, Neil Conway <neilc(at)samurai(dot)com>, pgsql-patches(at)postgresql(dot)org, Joe Conway <mail(at)joeconway(dot)com> |
| Subject: | Re: [HACKERS] array_accum aggregate |
| Date: | 2006-10-13 13:56:09 |
| Message-ID: | 29129.1160747769@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> What this really calls for is a type that users are forbidden to
> interact with directly. Basically, the type may only be used by C
> functions and such C functions may not appear in an SQL query.
That's not really the flavor of solution I'd like to have. Ideally,
it'd actually *work* to write
my_ffunc(my_sfunc(my_sfunc(null, 1), 2))
and get the same result as aggregating over the values 1 and 2. The
trick is to make sure that my_sfunc and my_ffunc can only be used
together. Maybe we do need a type for each such aggregate ...
In any case, "internal" isn't quite the right model, because with that,
the type system is basically disclaiming all knowledge of the data's
properties. With an "aggregate_state" datatype, the type system would
be asserting that it's OK to use this type (or more accurately, these
functions) in an aggregate.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2006-10-13 13:58:00 | Re: On status data and summaries |
| Previous Message | Andrew Sullivan | 2006-10-13 13:49:16 | Re: On status data and summaries |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2006-10-13 14:19:27 | Re: test_fsync on MinGW(win32) |
| Previous Message | Martijn van Oosterhout | 2006-10-13 08:05:57 | Re: [HACKERS] array_accum aggregate |