A Small psql Suggestion

At the risk of starting a +1 snowball or a divergent argument...

On Tue, Jan 31, 2023 at 10:16 AM Raymond Brinzer <ray.brinzer@gmail.com>
wrote:

Greetings,

There is (for me) a small speed bump in psql. I think it's worth
mentioning, minor though it is, because psql is such a polished tool
generally, and because it's something which affects me many, many times a
day.

As it is, \d is a shortcut for \dtmvs. What I actually want to see, on a
regular basis, are my relations: \dtmv. Most of the time, the sequences
are clutter. If my habits are like most people's in this (and I suspect
they are), excluding sequences from \d would optimize for the common case.

+1

Of course, I don't generally have that many relations that the few
sequences that show up are cause for issue, but it would be nice to not
have to parse them visually.

-m

On Tue, Jan 31, 2023 at 11:17:16AM -0500, Raymond Brinzer wrote:

Greetings,

There is (for me) a small speed bump in psql. I think it's worth
mentioning, minor though it is, because psql is such a polished tool
generally, and because it's something which affects me many, many times a
day.

As it is, \d is a shortcut for \dtmvs. What I actually want to see, on a
regular basis, are my relations: \dtmv. Most of the time, the sequences
are clutter. If my habits are like most people's in this (and I suspect
they are), excluding sequences from \d would optimize for the common case.

Perhaps just add this yourself?
\set d '\\dtmv'
and then
:d

or just bind \dtmv to some key like f1 or something like this?

Best regards,

depesz

I was really busy with work last week, so I didn't get around to thanking
you, depesz. Setting d is a clever trick which hadn't occurred to me, and
it has indeed made things nicer for me.

I do think it would be a good thing to actually change in psql
nevertheless, since I think the suggested behavior is better most of the
time, especially if all or most of your tables have sequences. The
built-in ability to work around it (to a good approximation of the desired
behavior) certainly does diminish the importance of the issue, though such
a solution won't be obvious to most people.

Again, though, my thanks. This has been like a rough spot on the handle of
a tool: trivial for occasional use, prone to raise a blister over
thousands of repetitions.

On Wed, Feb 1, 2023 at 11:04 AM hubert depesz lubaczewski <depesz@depesz.com>
wrote:

On Tue, Jan 31, 2023 at 11:17:16AM -0500, Raymond Brinzer wrote:

Greetings,

There is (for me) a small speed bump in psql. I think it's worth
mentioning, minor though it is, because psql is such a polished tool
generally, and because it's something which affects me many, many times a
day.

As it is, \d is a shortcut for \dtmvs. What I actually want to see, on a
regular basis, are my relations: \dtmv. Most of the time, the sequences
are clutter. If my habits are like most people's in this (and I suspect
they are), excluding sequences from \d would optimize for the common

case.

Perhaps just add this yourself?
\set d '\\dtmv'
and then
:d

or just bind \dtmv to some key like f1 or something like this?

Best regards,

depesz

--
Ray Brinzer

Front end: Access 365
Back end: Postgres 9.4
(I know, we are in the process of upgrading)

I'm getting some cases where the SQL sent from MS-Access is failing.
Looking at the postgres log shows that the field names and table names are
not being quoted properly.
It has been my experience that Access usually does a better job at
converting the queries than I would have expected, but not in this instance.

For example

Access: connection.Execute "UPDATE [" & strTable & "] SET [" & strTable &
"].[InsertFlag] = Null" _
& " WHERE ((([" & strTable & "].[InsertFlag])=" & lngCurrUID & "));", ,
adCmdText Or adExecuteNoRecords
Note that InsertFlag is bracketed the same way in both instances.

PSQL: UPDATE "public"."Orders" SET InsertFlag=NULL WHERE ("InsertFlag" =
166 )
Note that InsertFlag is quoted once but not the other time.
Of course this gives the error: column "insertflag" of relation "Order
Items" does not exist at character 35

Any suggestions on where to look?

Thanks,
Brad.

On 2/7/23 16:00, Brad White wrote:

Front end: Access 365
Back end: Postgres 9.4
(I know, we are in the process of upgrading)

I'm getting some cases where the SQL sent from MS-Access is failing.
Looking at the postgres log shows that the field names and table names
are not being quoted properly.
It has been my experience that Access usually does a better job at
converting the queries than I would have expected, but not in this instance.

For example

Access: connection.Execute "UPDATE [" & strTable & "] SET [" & strTable
& "].[InsertFlag] = Null" _
    & " WHERE ((([" & strTable & "].[InsertFlag])=" & lngCurrUID &
"));", , adCmdText Or adExecuteNoRecords
Note that InsertFlag is bracketed the same way in both instances.

PSQL: UPDATE "public"."Orders" SET InsertFlag=NULL  WHERE ("InsertFlag"
= 166 )
Note that InsertFlag is quoted once but not the other time.
Of course this gives the error: column "insertflag" of relation "Order
Items" does not exist at character 35

Any suggestions on where to look?

1) Do not tack on to an existing thread, create a new post.

2) Where is the query coming from, manually created code or something
ORM like?

3)

Thanks,
Brad.

--
Adrian Klaver
adrian.klaver@aklaver.com

1) Do not tack on to an existing thread, create a new post.
Yup. Failure on my part.
I'll repost.