Re: Proposition for autoname columns

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.

In response to

Browse pgsql-hackers by date

  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?