On 12/13/22 18:22, Tom Lane wrote:
"David G. Johnston" writes:
I'm more keen on the idea of having the system understand when an ORDER BY
is missing - that seems like what users are more likely to actually do.
That side of it could perhaps be useful, but not if it's an unintelligent
analysis.
"David G. Johnston" writes:
> I'm more keen on the idea of having the system understand when an ORDER BY
> is missing - that seems like what users are more likely to actually do.
That side of it could perhaps be useful, but not if it's an unintelligent
analysis. If someone has a perfectly safe q
On Tue, Dec 13, 2022 at 9:45 AM Ronan Dunklau
wrote:
> Le mardi 13 décembre 2022, 16:13:34 CET Tom Lane a écrit :
> > Accordingly, I find nothing at all attractive in this proposal.
> > I think the main thing it'd accomplish is to drive users back to
> > the bad old days of ordering-by-subquery,
Ronan Dunklau writes:
> Le mardi 13 décembre 2022, 16:13:34 CET Tom Lane a écrit :
>> Accordingly, I find nothing at all attractive in this proposal.
>> I think the main thing it'd accomplish is to drive users back to
>> the bad old days of ordering-by-subquery, if they have a requirement
>> we fa
Le mardi 13 décembre 2022, 16:13:34 CET Tom Lane a écrit :
> Accordingly, I find nothing at all attractive in this proposal.
> I think the main thing it'd accomplish is to drive users back to
> the bad old days of ordering-by-subquery, if they have a requirement
> we failed to account for.
I think
Ronan Dunklau writes:
> Le mardi 13 décembre 2022, 14:05:10 CET Vik Fearing a écrit :
>> On 12/13/22 13:55, Magnus Hagander wrote:
>>> On Tue, Dec 13, 2022 at 1:51 PM Vik Fearing
>>> wrote:
However, it is completely useless for things like AVG() or SUM(). If
you include it, the aggreg
Le mardi 13 décembre 2022, 14:05:10 CET Vik Fearing a écrit :
> On 12/13/22 13:55, Magnus Hagander wrote:
> > On Tue, Dec 13, 2022 at 1:51 PM Vik Fearing
wrote:
> >> However, it is completely useless for things like AVG() or SUM(). If
> >> you include it, the aggregate will do the sort even thou
On 12/13/22 14:25, Isaac Morland wrote:
On Tue, 13 Dec 2022 at 07:50, Vik Fearing wrote:
I am proposing something like pg_aggregate.aggordering which would be an
enum of behaviors such as f=Forbidden, a=Allowed, r=Required. Currently
all aggregates would have 'a' but I am thinking that a lot
On Tue, 13 Dec 2022 at 07:50, Vik Fearing wrote:
I am proposing something like pg_aggregate.aggordering which would be an
> enum of behaviors such as f=Forbidden, a=Allowed, r=Required. Currently
> all aggregates would have 'a' but I am thinking that a lot of them could
> be switched to 'f'. In
On 12/13/22 13:55, Magnus Hagander wrote:
On Tue, Dec 13, 2022 at 1:51 PM Vik Fearing wrote:
The standard only defines an ORDER BY clause inside of an aggregate for
ARRAY_AGG(). As an extension to the standard, we allow it for all
aggregates, which is very convenient for non-standard things l
On Tue, Dec 13, 2022 at 1:51 PM Vik Fearing wrote:
> The standard only defines an ORDER BY clause inside of an aggregate for
> ARRAY_AGG(). As an extension to the standard, we allow it for all
> aggregates, which is very convenient for non-standard things like
> string_agg().
>
> However, it is
The standard only defines an ORDER BY clause inside of an aggregate for
ARRAY_AGG(). As an extension to the standard, we allow it for all
aggregates, which is very convenient for non-standard things like
string_agg().
However, it is completely useless for things like AVG() or SUM(). If
you
12 matches
Mail list logo
