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

From Andrew Dunstan
Subject Re: Proposition for autoname columns
Date
Msg-id 869f0039-30e0-03a6-b709-1802a0a58cc3@dunslane.net
Whole thread Raw
In response to Re: Proposition for autoname columns  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Proposition for autoname columns  (Eugen Konkov <kes-kes@yandex.ru>)
List pgsql-hackers
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?


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




pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Online checksums patch - once again
Next
From: Andrew Gierth
Date:
Subject: Re: Strange GiST logic leading to uninitialized memory access in pg_trgm gist code