On Thu, Oct 12, 2006 at 06:58:52PM -0400, Tom Lane wrote:
> I wrote:
> > aggregate_state would have no other uses in the system, and its input
> > and output functions would raise an error, so type safety is assured
> > --- there would be no way to call either the sfunc or ffunc "manually",
> > exc
Patch applied. Thanks.
---
Hiroshi Saito wrote:
> Hi.
>
> I wanted to see this difference. It is somewhat ad hoc.
> However, It is more effective than it doesn't show it at all.
>
> -- MinGW(win32) --
> $ test_fsync
> Si
Martijn van Oosterhout 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. Ideall
* Tom Lane ([EMAIL PROTECTED]) wrote:
> 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_
Stephen Frost <[EMAIL PROTECTED]> writes:
>> 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))
> In general I like this idea but there are some complications, the main
> one being where would the memory
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > The other issue is, in the above scenario
> > is it acceptable to modify the result of my_sfunc(null, 1) in the ,2
> > call?
>
> Yes, because the only place a nonnull value of the type could have come
> from is a
Stephen Frost <[EMAIL PROTECTED]> writes:
>>> Additionally, we'd have to be
>>> able to mark the types as being polymorhpic along the same lines as
>>> anyelement/anyarray.
>>
>> What for?
> So that the finalfunc can be polymorphic along the lines of my suggested
> aaccum_sfunc(anyarray,anyelement
Hi,
here is a patch implementing an index recommendation advisor for
7.4.13. It consists of extensions to the planner and the catalog as
well as a command line tool pg_advise in contrib. The index advisor
works as part of the EXPLAIN statement, i.e. by
set enable_indexadvisor=true;
explain
Kai-Uwe Sattler wrote:
Hi,
here is a patch implementing an index recommendation advisor for
7.4.13. It consists of extensions to the planner and the catalog as
well as a command line tool pg_advise in contrib. The index advisor
works as part of the EXPLAIN statement, i.e. by
set enable_indexa
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Kai-Uwe Sattler wrote:
>> here is a patch implementing an index recommendation advisor for
>> 7.4.13.
> You know we don't put new features on stable branches, right?
I think you forgot the context --- somebody asked Kai-Uwe to send what
he had. There
10 matches
Mail list logo