131–140 of 167 posts
I may be wrong, but isn't "overlapping" just "meeting_a.starts_at meeting_b.starts_at"? Or in words: There is an overlap if meeting A starts before meeting B ends and meeting A ends after meeting B starts. So the scenario described looks way more complex as it actual seems to be.
After you're done with that corner case, you may find it better to determine if they don't overlap and negate that.
I may be wrong, but isn't "overlapping" just "meeting_a.starts_at meeting_b.starts_at"? Or in words: There is an overlap if meeting A starts before meeting B ends and meeting A ends after meeting B starts. So the scenario described looks way more complex as it actual seems to be.
I believe it's about the common case of two events sharing a single (infinitely small) point of time: meeting A from 3 to 4, followed by meeting B from 4 to 5. Those two time periods do overlap mathematically, but not physically: they share the common point of "4", even if that point has duration 0. I know the iCal standard goes into this for a bit.
Earlier quoted context omitted.
Something I always liked but have never done -- start auto-increment IDs at some number other than 1. I worked on a system where account IDs started with 1000000, invoice IDs started with 2000000, etc. That way, if you saw a random number laying around like "1001234", you knew it was an account ID. "2000123", an invoice! I don't remember how often it helped things, but it was more than 0 times, and it always "felt" g…
I use this for internal items, as in: real customer IDs start at 10,000, so we have 9,999 possible users/invoices/whatever for our own usage in the database. That makes it easy to filter demo accounts of your sales employees, or production test accounts, in queries: just add an offset. Re: the upper bound: if you reach a million customers, you have lots of other nice problems, like how to spend all the money they ear…
You could use "is_test_account" or whatnot, but that adds an unnecessary column (for ~99% of records)
I like this -- will keep it in mind!
Earlier quoted context omitted.
We use them in production, they work fine. You probably want to enable use_remote_estimate for postgres_fdw though.
Could you describe for what use case are you using foreign data wrapper in production?
It pushed alot of complexity down away from higher-level app developers not familiar with ES patterns.
[0]: https://github.com/matthewfranglen/postgres-elasticsearch-fd...
Earlier quoted context omitted.
Yeah I recognize the arguments for UUID keys: - Avoids people being able to just iterate through records, or to discover roughly how many records of a thing you have - Allows you to generate the key before the row is saved I think I default to auto-increment ID's due to: - Familiarity bias - They have a temporal aspect to them (IE, I know row with ID 225 was created before row with ID 392, and approximately when they…
> They have a temporal aspect to them (IE, I know row with ID 225 was created before row with ID 392, and approximately when they might be created) UUIDv7 (currently a draft spec[0]) are IDs that can be sorted in the chronological order they were created In the meantime, ulid[1] and ksuid[2] are popular time-sortable ID schemes, both previously discussed on HN[3] [0] https://datatracker.ietf.org/doc/html/draft-peabod…
We ended up implementing UUIDv7 in our ID generation library https://github.com/MatrixAI/js-id. And we have a number of tests ensuring that it is truly monotonic even across process restarts.
See IdSortable.
Earlier quoted context omitted.
Yeah I recognize the arguments for UUID keys: - Avoids people being able to just iterate through records, or to discover roughly how many records of a thing you have - Allows you to generate the key before the row is saved I think I default to auto-increment ID's due to: - Familiarity bias - They have a temporal aspect to them (IE, I know row with ID 225 was created before row with ID 392, and approximately when they…
Something I always liked but have never done -- start auto-increment IDs at some number other than 1. I worked on a system where account IDs started with 1000000, invoice IDs started with 2000000, etc. That way, if you saw a random number laying around like "1001234", you knew it was an account ID. "2000123", an invoice! I don't remember how often it helped things, but it was more than 0 times, and it always "felt" g…
Positive IDs were home-grown, negative ones were Unique Feature Identifiers from some old GNS system import (from some ancient US Government/Military dataset).
Then when something had to be edited/replaced/created it would possibly change a previously negative ID to positive, fun times.
Earlier quoted context omitted.
> If you know a good usecase for ACL in database for OLTP workflows, I'm all ears. Here's one that's meaningful to me. We have a single database with five different applications that access it, each of them managed by a separate team. By enforcing access constraints in the database we guarantee the access constraints will be applied in all cases. It is difficult to ensure that in application code managed by separate…
I see, thanks for your input. Most of the workflows I worked on involved provisioning one database per app, so I hadn't entertained this angle. Are there any risks to changing ACL rules on a production database server from a stability perspective?
i've never seen anything impact postgres stability. they test their code.
i've made DDL changes on live systems; that seems far more concerning than ACLs.