On 22.02.23 21:38, Andres Freund wrote:
On 2023-02-20 16:08:00 +0100, Peter Eisentraut wrote:
On 11.02.23 20:24, Andres Freund wrote:
I think we should just do it and not care about what breaks. There has
never been any guarantee about these.
FWIW, "most" other SQL implementations appear to
On 2/22/23 23:03, Tom Lane wrote:
Andres Freund writes:
We could just do something like printing __. So
something like avg(reltuples / relpages) would end up as
avg_reltuples_float48div_relpages.
Whether that's worth it, or whether column name lengths would be too painful,
IDK.
I think you'd
Andres Freund writes:
> On 2023-02-22 16:38:51 -0500, Tom Lane wrote:
>> The proposal so far was just to handle a function call wrapped
>> around something else by converting to the function name followed
>> by whatever we'd emit for the something else.
> SELECT sum(relpages), sum(reltuples),
Hi,
On 2023-02-22 16:38:51 -0500, Tom Lane wrote:
> Vladimir Churyukin writes:
> > It doesn't need to be perfect, but it needs to be consistent. So far you
> > proposed a rule to replace () with _. What is the plan for expressions, how
> > to convert them to names (with deduplication I guess?,
Vladimir Churyukin writes:
> It doesn't need to be perfect, but it needs to be consistent. So far you
> proposed a rule to replace () with _. What is the plan for expressions, how
> to convert them to names (with deduplication I guess?, because there could
> be 2 similar expressions mapped to the
On Wed, Feb 22, 2023, 12:40 PM Andres Freund wrote:
> Hi,
>
> On 2023-02-11 12:47:04 -0800, Vladimir Churyukin wrote:
> > That is a good idea for simple cases, I'm just curious how it would look
> > like for more complex cases (you can have all kinds of expressions as
> > parameters for
Hi,
On 2023-02-11 12:47:04 -0800, Vladimir Churyukin wrote:
> That is a good idea for simple cases, I'm just curious how it would look
> like for more complex cases (you can have all kinds of expressions as
> parameters for aggregate function calls).
> If it works only for simple cases, I think
Hi,
On 2023-02-20 16:08:00 +0100, Peter Eisentraut wrote:
> On 11.02.23 20:24, Andres Freund wrote:
> I think we should just do it and not care about what breaks. There has
> never been any guarantee about these.
>
> FWIW, "most" other SQL implementations appear to generate column names like
>
On 20.02.23 16:17, David G. Johnston wrote:
I think we should just do it and not care about what breaks. There has
never been any guarantee about these.
I'm going to toss a -1 into the ring but if this does go through a
strong request that it be disabled via a GUC. The ugliness of
On Mon, Feb 20, 2023 at 8:08 AM Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 11.02.23 20:24, Andres Freund wrote:
> >
> > I think on a green field it'd be clearly better to do something like the
> > above. What does give me pause is that it seems quite likely to break
> >
On 11.02.23 20:24, Andres Freund wrote:
Not useful column names:
SELECT SUM(reads), SUM(writes) FROM pg_stat_io;
column names: sum, sum
So i often end up manually writing:
SELECT SUM(reads) AS sum_reads, SUM(writes) AS sum_writes, ... FROM pg_stat_io;
Of course we can't infer useful column
On Sat, Feb 11, 2023 at 3:47 PM Vladimir Churyukin
wrote:
> For backwards compatibility I guess you can have a GUC flag controlling
> that behavior that can be set into backwards compatibility mode if required.
> The previous functionality can be declared deprecated and removed (with
> the flag)
That is a good idea for simple cases, I'm just curious how it would look
like for more complex cases (you can have all kinds of expressions as
parameters for aggregate function calls).
If it works only for simple cases, I think it would be confusing and not
very helpful.
Wouldn't it make more
Hi,
A common annoyance when writing ad-hoc analytics queries is column naming once
aggregates are used.
Useful column names:
SELECT reads, writes FROM pg_stat_io;
column names: reads, writes
Not useful column names:
SELECT SUM(reads), SUM(writes) FROM pg_stat_io;
column names: sum, sum
So i
14 matches
Mail list logo