č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
>
>
>
>
