Re: Can we go beyond the standard to make Postgres radically better?

On 2022-02-12 20:50:57 +0100, Peter J. Holzer wrote:
> On 2022-02-12 01:18:04 +0100, Andreas 'ads' Scherbaum wrote:
> > On 10/02/2022 18:22, Peter J. Holzer wrote:
> > > On 2022-02-09 21:14:39 -0800, Guyren Howe wrote:
> > > > Examples of small things Postgres could have:
> > > >
> > > > • SELECT * - b.a_id from a natural join b
> > >
> > > My use case for such a feature are tables which contain one column (or a
> > > small number of columns) which you usually don't want to select: A bytea
> > > column or a very wide text column. In a program I don't mind (in fact I
> > > prefer) listing all the columns explicitely, but exploring a database
> > > interactively with psql typing lots of column names is tedious
> > > (especially since autocomplete doesn't work here).
> >
> > Maybe for this specific use case it's easier to teach psql how to do that,
[...]
> I think the easiest way to get the columns would be to EXPLAIN(verbose)
> the query. Otherwise psql (or whatever your shell is) would have to
> completely parse the SQL statement to find the columns.

A shell could also provide an "expand select list" function using
explain.

In fact, you can sort of do that manually:

1) Prefix your query with explain(verbose)
2) Copy the "Output:" line of the top node.
3) Edit your query, remove the explain(verbose) and replace the select
list with the content of the clipboard
4) (optional) remove any unwanted columns

A bit cumbersome but less cumbersome than typing/copying lots of column
names from the result of a previous query or \d.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp(at)hjp(dot)at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"