On Wed, Oct 28, 2015 at 1:38 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Marko Tiikkaja <ma...@joh.to> writes: > > Here's a patch for the aggregate function outlined by Corey Huinker in > > CADkLM=foA_oC_Ri23F9PbfLnfwXFbC3Lt8bBzRu3=cb77g9...@mail.gmail.com . I > > called it "onlyvalue", which is a horrible name, but I have nothing > > better to offer. (Corey called it "only", but that doesn't really work > > since ONLY is a fully reserved keyword.) > > On the name front, maybe think "single" rather than "only"? This might > lead to "single()" or "single_value()", or "singleton()" if you want to > sound highbrow. > > On the semantics front, I'm not sure that I like excluding nulls from the > input domain. I'd rather that it acted like IS NOT DISTINCT, ie, nulls > are fine as long as all the input values are nulls. The implementation > would need some work for that. > homogeneous() ? It is basically an assertion function since in most cases where you would use this you needn't use a function at all but instead simply place the column in the GROUP BY clause. I have at various times desired having various assertion functions that return the input value if the assertion is met but causes a query error if it is not. That said functions can be both scalar and aggregate oriented makes sense. Adding just this one function in seems like it adds a partial feature to -core. I'd rather it bake more in PGXN before considering putting it into core. There doesn't seem to be any hard need or benefit to doing so at this time. I would probably stick to the concept of assertion and call it something like "assert_nongrouping()" to denote that the input does not cause multiple groups to be created due to their being multiple values. David J.
