Thread: A Small psql Suggestion
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.
Just $0.02, submitted for your gracious consideration.
--
Ray Brinzer
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)
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 adExecuteNoRecordsNote 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.
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.