psql \d sequence display

Started by Peter Eisentrautalmost 9 years ago3 messageshackers
Beta feature

Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.

won't retrysuccessCI history

You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:

docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t37466
psql -h localhost -U postgres

Built from patchset v1 (message #1), July 27, 2026 at 10:09 PM.

Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:

git clone --branch t37466_1 https://github.com/hackorum-dev/postgres.git

In a checkout you already have, add the fork once:

git remote add hackorum https://github.com/hackorum-dev/postgres.git

then, for this patchset and every later one:

git fetch hackorum t37466_1 && git checkout t37466_1

Patchset v1 (message #1) is on t37466_1

Jump to latest
#1Peter Eisentraut
peter_e@gmx.net

In PostgreSQL 10, the sequence metadata moved from the sequence
"relation" to a system catalog. The psql \d sequence command was not
updated for that. (It just did SELECT * FROM seq and there were no
tests, so this was missed.) Attached is a patch that fixes that up,
taking the opportunity to design a more useful sequence display that is
not merely hacked on to the general relation display.

This should be fixed for PG10, so if you have any feedback on the
design, please let me know soon.

Examples are in the attached patch.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachments:

t37466_1
0001-psql-Update-d-sequence-display.patchtext/plain; charset=UTF-8; name=0001-psql-Update-d-sequence-display.patch; x-mac-creator=0; x-mac-type=0Download+135-81
#2Fabien COELHO
coelho@cri.ensmp.fr
In reply to: Peter Eisentraut (#1)
Re: psql \d sequence display

Hello,

This should be fixed for PG10, so if you have any feedback on the
design, please let me know soon.

Works for me on head against a 9.6 server, which is good.

My 0.02 €:

\d+ does not show more.

Maybe Type, Min, Max, Inc & Cycles are enough for \d?

The next/future or last/previous value is not shown. If one could be
available it would be nice to have?

Maybe some names are a little large, eg "Increment" could be "Inc.".
The value is nearly always 1?

Not sure why it is "Cycles" (plural) instead of "Cycle".

The non regression test could also show a more esoteric sequence (cyclic,
...).

There is no documentation. Maybe none is needed.

I do not understand why some queries have "... \n" "... \n" and others
have "\n ..." "\n ...". I would suggest to homogeneize around the former,
because "\nFROM ..." is less readable.

--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#3Peter Eisentraut
peter_e@gmx.net
In reply to: Fabien COELHO (#2)
Re: psql \d sequence display

On 9/25/17 13:53, Fabien COELHO wrote:

\d+ does not show more.

Maybe Type, Min, Max, Inc & Cycles are enough for \d?

That seems kind of arbitrary. Start and Cache are just as relevant.

The next/future or last/previous value is not shown. If one could be
available it would be nice to have?

You can get those from the sequence. Running \d on a table doesn't show
the table data either. So I think this is a valid distinction.

Maybe some names are a little large, eg "Increment" could be "Inc.".
The value is nearly always 1?

Yeah, but then that would look weird if only one heading were
abbreviated. The total display width is good, so we don't need to
squeeze it too hard.

Not sure why it is "Cycles" (plural) instead of "Cycle".

This is meant to be a verb, as in "does it cycle?". I have changed it
to "Cycles?" to match other similar headings.

I do not understand why some queries have "... \n" "... \n" and others
have "\n ..." "\n ...". I would suggest to homogeneize around the former,
because "\nFROM ..." is less readable.

Yeah that is a bit ugly, but I have just moved existing code around.

I have now committed my patch with minor adjustments, so we have
something working for PG10.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers