radimm

OP here - I'm going to follow up with the separate article on pgTap. But the goals of both tools is slightly different in my mind.

For now only fixtures support transaction as cleanup options, but that's a good point that tested queries might also modify the queries.

I will definitely reach out, just give me bit of time to mentally recover from the exposure and got some meet ups where I promised to deliver some presentations and they will consume a lot of my spare free time.

It's not unreasonable view - noted, will add to my list. Thank you!

At this point it supports initialization through the fixtures systems (like inline SQL or SQL files). At the moment they have fixed order, which might lead to some limitations, but I'm already thinking about some pre/post test setup hooks and full schema handling as well (for full schema reloads).

Plus I have whole set of other requirements where RegreSQL suddenly seems to be a good solution.

And without sounding cliche - Thank you for the comment! This is exactly why I forced myself to go public and get this level of feedback.

The primary direction is to make RegreSQL part of CI/CD pipelines. In theory in can be run against production DB, but I believe it needs much more work to provide real value there. Thank you for the comment!

OP here - I do agree some of the problems that come with SQL/ORM queries are pretty horrendous and that's exactly where I would like RegreSQL going. For now I can't promise the particular direction, but comments like this are the reason why I pushed myself to release it and keep it beyond my own playground. Thank you!

this is same with GCP Cloud SQL and RDS (there I need to double check). They really don't want you to access the underlying FS.

Lived through it and while it might be similar, Microsoft had monopoly at that point (90% and higher share in personal computers - depending on the market). Apple is nowhere near that.

That’s PGRX - not PostgreSQL

Author here, I hope I made it clear pg_cron is available everywhere. Thank you for pg_cron though!

Autor here. Generally I feel much more confident about external services 'pulling' the status. But I have something cooking up to reduce the friction of external calls and possible process blocking...

You are not wrong here. This is what I'm trying to get to with boringSQL - create more 'packaging' around things to improve developer UX while developing SQL based solutions. Be it APIs, complex apps and everything around.

Yes, application issues own JWT tokens - specifically in `public.create_jwt`

Author here - you are absolutely correct. Damn, during the last proof-reading one function got lost. Will fix it ASAP

Thank you for correction! Indeed - it's one of those things i've read but practically avoided it for historic reasons and therefore forgot about it.

Author here - this is my primary goal, exposing the complexity developer might not even think about. Can't even count number of instances seemingly inconspicuous changes caused incident.

"Works on my DB" is new "works on my machine" (and don't trademark it, please :)))

On other hand index bloat can be solved relatively easily using concurrent reindex (since 12.x if I remember correctly).

Thanks for the good point. You are right, pg_squeeze is not available there. Will update post tonight for clarity. I know it's available on GCP though.

Consider time it takes to rewrite the table, downtime you can afford and the disk space you have. My goal is to write bit more about the cases that go beyond the usual "works on my 100MB" scenario.

Yes, anytime you have untrivial amount of the data, you go for

1. Create new column 2. Backfill new column over time (manual, triggers, etc.) 3. During small downtime drop/rename (i.e. swap the columns).

Oh thanks. Will definitely try it as well.

Hmm, somehow it does not work at all in Firefox Developer edition though. Thought I'm missing something at first.

All good until your ZSH gets heavyweight and slow. Started using fish and never looked back

Not thinking of leaving - it’s small niche app and don’t have much incentives to migrate.

Kind of agree. So far as 1password user I can't see much reasons to use it. Or where does it stand with the built-in password managers.

Guess the education and availability of the password managers can't hurt in long run.

I second that. For me it's worse actually during times when I would normally use dark mode (i.e. evening). My 40-something eyes can get tired while having contact lenses and then dark mode is not so much helpful.

When switching to glasses it's actually bit better.

Thanks for the confirmation. As mentioned I'm not saying no to it. It is really that "really understand" part which holds me back for now - mainly the observability and dealing with edge cases in high-throughput environment.

Having recently heard a lot of about PostgreSQL in Kubernetes (cloudNativePG for example) it always makes me wonder about the actual load and the complexity of the cluster in the question.

> This is the reason why we were able to easily cope with 2M+ requests in less than 24h when Midnight Society launched

This gives the answer, while it's probably not evenly distributed gives 23 req/sec (guess peak 60 - 100 might be already stretching it). Always wonder about use cases around 3 - 5k req/sec as minimum.

[edit] PS: not really ditching neither k8s pg nor AWS RDS or similar solutions. Just being curious.

My PHEV ICE engine turns on from time to time and keeps on running for short periods of time.

I believe it last happened on Friday when I started the car and it was on for roughly 10 minutes. Have to say I was really wondering "what's wrong with the car" :)

Another thing that car is having is pressurized gasoline tank to avoid degradation of the fuel. If I'm correct this is reason behind it https://publications.lib.chalmers.se/records/fulltext/238063...

On-line debugging proxy. Sort of firebug running remotely with additional functionality like debug, mock, rewrite, or analyze requests. Together with further enhancements for development/testing of online and mobile applications, services and APIs.