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 ge
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), 1+1
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?, be
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 aggregate
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 it
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 th
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
> > exi
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 name
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 sense
13 matches
Mail list logo
