From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, Eugen Konkov <kes-kes(at)yandex(dot)ru>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposition for autoname columns |
Date: | 2020-11-12 05:52:50 |
Message-ID: | CAKFQuwa5ZjW40MuJBEd--wM5v74xJ_ZiDfxXOMpw=bNjvCLd3A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 11, 2020 at 5:56 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Thu, Nov 12, 2020 at 12:18:49AM +0000, Dagfinn Ilmari Mannsåker wrote:
> > Bruce Momjian <bruce(at)momjian(dot)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.
>
>
For the user an operator and a function are different ways to invoke the
same underlying thing using different syntax. I'm not seeing how this
syntax difference makes this any easier to implement for explicit function
invocation compared to operator function invocation.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2020-11-12 05:58:59 | Re: Add statistics to pg_stat_wal view for wal related parameter tuning |
Previous Message | Pavel Stehule | 2020-11-12 05:23:06 | Re: Is it useful to record whether plans are generic or custom? |