Re: Proposition for autoname columns - Mailing list pgsql-hackers

From Eugen Konkov
Subject Re: Proposition for autoname columns
Date
Msg-id 1547455226.20201112161450@yandex.ru
Whole thread Raw
In response to Re: Proposition for autoname columns  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Proposition for autoname columns  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: Proposition for autoname columns  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Hello Andrew,

Thursday, November 12, 2020, 3:19:39 PM, you wrote:


> On 11/11/20 7:55 PM, Bruce Momjian wrote:
>> On Thu, Nov 12, 2020 at 12:18:49AM +0000, Dagfinn Ilmari Mannsåker wrote:
>>> Bruce Momjian <bruce@momjian.us> writes:
>>>> I think we could do it, but it would only work if the column was output
>>>> as a single json value, and not a multi-key/value field.  I am afraid if
>>>> we tried to do it, the result would be too inconsistent to be useful.
>>> Could this be done via the support function, so that the top-level
>>> operator/function in each select list item can return a suggested column
>>> name if the relevant arguments are constants?
>> Yes, the user explicitly calling a function would be much easier to
>> predict.
>>


> I suspect this is doomed to failure. There is no guarantee that the path
> expression is going to be static or constant across rows. Say you have
> this table:


> x: foo, j: {"foo": 1, "bar": 2}

> x: bar  j: {"foo": 3, "bar": 4}


> and you say:


>   select j->>x from mytable;
> What should the column be named?

Suppose it should be named 'as x'


> I think we'd be trying to manage a set of corner cases, and all because
> someone didn't want to put "as foo" in their query. And if we generate a
> column name in some cases and not in others there will be complaints of
> inconsistency.


> cheers


> andrew


> --
> Andrew Dunstan
> EDB: https://www.enterprisedb.com




--
Best regards,
Eugen Konkov




pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: truncating timestamps on arbitrary intervals
Next
From: Tomas Vondra
Date:
Subject: Re: Additional improvements to extended statistics