That would be hearsay, yes?

Why? He heard you say it and can testify to it.

Repeating something that you heard someone say is the literal definition of hearsay. Typically courts want to hear about facts from people who actually know those facts, not someone who heard someone talking about those facts.

This would fall under the "statement against interest" exception to hearsay, though, because obviously the person who originally said the thing isn't going to want to admit in court that they were committing a crime.

The fact is that he said it.

You aren't repeating a fact you heard him say, you are reporting what you heard him say.

Reporting what you heard someone say is the literal definition of hearsay.

If you want to use someone saying something as evidence in court, they need to say it to the court as directly as is practical. If the person saying it isn't going to say it directly to the court, then it needs to be justified with one of the exceptions to the hearsay rule.

In this example, it would be allowed because the person saying it wouldn't be willing to admit to a crime in court.

It's a statement not offered to prove the truth of the asserted statement - non-hearsay.

It would be hearsay if offered as evidence that you had meth in your pocket. It would not if offered in evidence you were enquiring about the legality, to show intent.

‾\(o O)/‾ maybe, IANAL

I bet their data is included too, for two reasons:

First, identity verification data for KYC is a little bit different from fast food or social media in that it's very difficult to live a normal life without being subject to any KYC checks. (I'm sure someone will chime in that they get paid in bitcoin and buy their groceries with cash.) If you are applying for some financial product or service that requires KYC, and they can't find any information about you, you will often either be denied that product or have to jump through a bunch of additional hoops to prove who you are. So it benefits CXOs to have their data included in these datasets, in fact if they are well paid they may well have more activity requiring KYC checks than the average person.

Second, and much more simply, one's own data often makes for a good test case since you know its accuracy.

I am not debating that they don't need KYC, I'm simply saying they probably use a more secure alternative than their own.

To turn it around, you should assume anyone in the dark alley is potentially dangerous, and not allow biases or racism to cause you to lower your guard to someone who may end up stabbing you.

You don't have to do anything. But as you say, they are the one in the position of power. If you are working on some side quest they don't see as valuable, it may not end well for you. Doubly so if you are shirking what they see as a high value task for your side quest.

It's not about what is right or who "should" do what, it's about securing the best outcome by making sure you and your manager have the same understanding, even if your manager isn't doing a good job of making sure you have the same understanding. (Also known as "managing upwards.")

Am I right to think this could be used to "inject" limits on the number of rows returned by a user query, or otherwise restrict what users see allowed to do?

I know it sounds silly/crazy but I have a use case where I would like to allow "mostly" trusted users to access the database directly and not through an API, but I need to apply some restrictions on their output.

It can but it's not the primary goal at the moment. If you want to restrict the number of rows returned, you can rewrite the query to add a LIMIT clause. To control which rows your users can see, you can use row-level security.

One thing I was thinking of doing is generating query plans asynchronously and blocking/cancelling queries that would otherwise be expensive and cause downtime. That's on the roadmap.

This is great. Where can I learn more like this?

I am interested in distributed systems and database internals (both traditional and new databases) but find that many database resources tend to be either introductory SQL queries or related to tuning.

Martin Kleppmann's book Designing Data-Intensive Applications is a great starting point if you're not familiar with it.

I personally like to find new distributed systems, and then learn what techniques they use.

For example learning how serf.io ises Vivaldi, how CockroachDB uses raft multi-group, or why FoundationDB has different processes and they each do.

I try to write interesting stuff on distributed systems, but there's a great discord created by eaton phil on software internals that has a lot of great discussions https://twitter.com/eatonphil

oh also, https://lobste.rs and filter by the `distributed` tag

As someone who lacks a formal CS education and wants to know more about how databases work, I have been eagerly awaiting this book. I also want some practical golang projects to work on so this is perfect! I'm so excited!