On Wed, Oct 28, 2015 at 1:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Marko Tiikkaja <marko@joh.to> writes: > Here's a patch for the aggregate function outlined by Corey Huinker in > CADkLM=foA_oC_Ri23F9PbfLnfwXFbC3Lt8bBzRu3=CB77G9_qw@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.
