ads' corner

With people moving away from Twitter, mostly to Mastodon, discovering the new accounts became a problem.

For people in the PostgreSQL community I created a website which lists different social media accounts. This website is part of the "PostgreSQL Person of the Week" interview project, however the data source is dynamic, and stored in a different repository. This allows me to keep the repository for the website private, but publish the data for the social media links - this data is public anyway. The interview repository is private, because who wants to see upcoming interviews anyway? ;-)

The interview website is made with Hugo, a static website generator. Normally Hugo looks for content, templates, and other data in the current directory - my private repository.

As part of compiling the website, Hugo can fetch external data, either in JSON or CSV format. This is using the getJSON() and the getCSV() functions, which can be used in Shortcodes, as example.

Ryan Lambert asks in this month's PGSQL Phriday:

• What non-relational data do you store in Postgres and how do you use it?
• Have you attempted non-relational uses of Postgres that did not work well? What was the problem?
• What are the biggest challenges with your data, whatever its structure?
• Bonus: How do you define non-relational data?

Looking over the many databases we operate at work, I can say that we are mostly a "relational shop". Almost every database we have uses relational structures, and does not attempt to go in on "full NoSQL", or "store non-relational data". Many of the databases are on the larger size, often in the hundreds of GB or even several TBs. We have good people in our dev teams who understand both PostgreSQL and SQL, and can develop a proper schema for the data, and write performant queries.

There are a few exceptions though, but at least for us it's only a small number. Whenever we retrieve or get data which comes in from web requests, we may store this as JSON, and then we use JSONb. Quite often however it's rather "storage as JSON", not "querying the JSON in the database". It's just more convenient to keep the data in JSON format all the way, instead of transforming it several times.

For one of my Ansible Playbooks I need the group name associated with a specific group id. Turns out there is not much documentation online how to do this, and I had to test it out.

For one project I need to insert the content of a local file into another file on the remote system, and the first file happens to be JSON. The JSON file is in compact format (jq --compact-output) and is supposed to stay this way. When Ansible reads the content of the file, it determines that the content is JSON, and parses the content into the variable - and along the way is uncompressing the format. Not what I want.