Viewing profile — tkejser

That's fair feedback and I shall take that into account in future blogs. Thanks for letting me know - you can stare yourself blind on that stuff

INFORMATION_SCHEMA is a good start, but it does not get you to full metadata flexibility. The columns you need just aren't there. It is good to have a standard for the metadata - b…

Merging to PostgreSQL core for something that needs to run on top of a Petabytes of data in the cloud, on Iceberg, with an advanced query planner and a high speed SIMD engine.... A…

To clarify a point: We store the row count of each operator in the query - not the actual row (that would indeed be madness!). Though we DO have tracing you can control that allow …

@da_chicken: You can read more about Snowflake ID in the Wiki page linked in the article. The short story: They are bit like UUID in that you can generate them across a system in a…

Thank you and yes! By making the entire architecture of the database visible via system objects - you allow the user to form a mental model of how the database itself works. Instea…

There are reasons for not USING. First, you need to be aware of the implicit disambiguration. When you join with USING, you are introducing a hidden column that represents both sid…

I didn't really write USING in anger until around 10 years ago, and I have been around a long time too. Not all databases support it. But once you start using it (pun) - a lot of n…

Hi All Original author here (no, I am not an LLM). First, a clarifying point on INFORMATION_SCHEMA. In the post I make it clear that this interface is supported by pretty much ever…