After quite a pause we continue the #fdw foreign data wrappers series of posts. In this post we will deal with MariaDB database access from within Postgres.
Every pure database developer could confirm that SQL language can be compared if not to the mother tongue but at least to any other foreign language you know. I.e. it's not a programming language. It's a more verbal, human-like tongue.
Jokes aside, this is just an expression of respect to the simple but very powerful language that allows you to "speak" to the different databases.
Being so widely used it's assumed by default today that every developer who ever wrote any piece of backend code must know SQL language.
It's hard to believe to myself that I'm writing these lines but war has come to my motherland, to my home.
And this is not a "Lord of the Rings" movie or book which I could pause or just put aside to
make a cup of tea and forget for a while about the Mordor and Orks.
This happens in reality. russian's orks led by putler invaded Ukraine.
Today is the 24th day of a heroic Ukrainian resistance.
russia's losses are unseen for them since World War II.
More than 14 000 of their soldiers have already been killed.
Thousands of armaments including tanks and planes are lost.
Main idea of this post is to demonstrate postgres major version upgrade process for the case when postgres runs within docker container.
Demonstrated approach uses pg_dumpall utility. In any case it does not pretend to be the "best" approach.
There are other options availabe such as pg_upgrade or setting up a replication server.
Moreover, for big databases pg_dumpall might be non optimal or even not feasible solution.
But as said at the beginning, idea is to demonstrate possible upgrade process for containerized postgres installation.
As many other databases Postgres supports access management framework via privileges which are provided to the users.
In terms of SQL it means a pair of commands GRANT and REVOKE.
To simplify things to the users postgres also supports massALL option for these commands.
Specifying either GRANT ALL or REVOKE ALL allows to apply command against multiple objects or against multiple privileges or for a mix of both.
Postgres foreign data wrapper for MongoDB database
This is part 4 of #fdw foreign data wrappers series of posts.
Earlier we have introduced wrappers for mysql, oracle and sqlite databases.
In this post we will connect to MongoDB database from within Postgres.
Компанія Microsoft зробила ще один крок для об’єднання різних технологій і методологій роботи з даними під одним дахом. Додавання обробки JSON дало можливість працювати з даними в стилі NOSQL Document DB. Добавання роботи з графовою моделлю даних дасть можливість працювати в стилі NOSQL Graph DB. Звичайно, що під капотом залишився той самий движок реляційних баз даних, на який навішали новий функціонал.
Being a long term fan of SQLite database I have always been a little bit disoriented by its documentation structure.
For me it seems enough cluttered and not easy to follow.
Apart of documentation structure there is another thing which is out of line to what we expect from Primary Key constraint definition in other RDBMS.
If you ever were wondering what is the difference between INT PRIMARY KEY and INTEGER PRIMARY KEY and why AUTOINCREMENT is not needed for default primary key generation in SQLite then this post might be interested for you.
It makes an attempt to describe these things in hopefully more easier format.
Note: I don't say official documentation is bad. It describes all these things.
I just want to filter out Primary Key related info and provide it in more consistent manner accompained by some examples.
This is part 3 of #fdw foreign data wrappers series of posts.
Initial part 1 was about connectivity to MySQL database.
Next part 2 was related to accessing Oracle database.
In this post we will access SQLite database from within Postgres.