čt 12. 11. 2020 v 16:59 odesílatel Andrew Dunstan <and...@dunslane.net> napsal:
> > On 11/12/20 9:14 AM, Eugen Konkov wrote: > > 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 <br...@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' > > > So if we then say: > > > select x, j->>x from mytable; > > > you want both result columns named x? That seems like a recipe for > serious confusion. I really don't think this proposal has been properly > thought through. > Why? It is consistent - you will get a value of key x, and anybody expects, so value should be different. Regards Pavel > > cheers > > > andrew > > > -- > Andrew Dunstan > EDB: https://www.enterprisedb.com > > > >