please adjust version numbers

[nukleus]

Hi, to my understanding, the version numbers in various files need to be adjusted to 2.0.1 (aka the current release). Otherwise, postgres lists it as version 1.0, yet the release name is 2.0.1.

[ahsanhadi]

Can you please explain what you mean by "postgres lists it as version 1.0"?

[nukleus]

postgres=# \dx
                            List of installed extensions
   Name    | Version |   Schema   |                   Description                    
-----------+---------+------------+--------------------------------------------------
 mysql_fdw | 1.0     | public     | Foreign data wrapper for querying a MySQL server
 plpgsql   | 1.0     | pg_catalog | PL/pgSQL procedural language
(3 rows)

Possible solution: sed -i "s,default_version = '1.0',default_version = '2.0.1'," mysql_fdw.control

[Kazmirchuk]

This is very confusing, especially when supporting customers, when they report having mysql_fdw 1.2, while the real extension version must be looked up either via a package manager or by calling the undocumented mysql_fdw_version()

I'd like to know if there are valid reasons why semantic versioning rules differ for GitHub and PostgreSQL.

[jeevanchalke]

The extension version and the package version are two different things and should not be linked to each other.

The extension version is bumped whenever there is a change in the extension's .sql file. That helps in upgrade cases too.

However, the package version is the release version containing features and bugs. The release version changes at every release, unlike the extension version.

mysql_fdw_version() should be used to get the package/release version, whereas to get an extension version, pg_extension catalog should be used.

Do you think we should document mysql_fdw_version()?

[Kazmirchuk]

yes, this function should be documented along with the justification for version mismatch, because mysql_fdw is in a minority in this respect. E.g. in TimescaleDB both version numbers are the same. I understand that FDW extensions are special since their interface from PG's PoV is minimal, and all feature development happens under the hood and doesn't require new upgrade scripts, but this is far from obvious and not mentioned in PG official docs either.

[jeevanchalke]

I believe this is a common practice used by the extension developers that the extension version and the package version differ. They are not related and hence can't be termed as there is a mismatch.

For example, postgres_fdw comes with every PG release. However, it is an extension, and its version only changes when its object changes. They both differ (PG version: 16.0 and postgres_fdw version: 1.1). Most other extensions, which are packaged/managed separately follow the same suite, for example, oracle_fdw, jdbc_fdw, etc.

Also, function mysql_fdw_version() is already documented at https://www.enterprisedb.com/docs/mysql_data_adapter/latest/11_identifying_data_adapter_version/

[Kazmirchuk]

until now I believed that README.md is your only documentation. There are no links to enterprisedb.com whatsoever. Ideally it should be a colorful icon "docs" at the top of the page.

[surajkharage19]

Hi @Kazmirchuk,

We have now added mysql_fdw documentation link in README file under commit - https://github.com/EnterpriseDB/mysql_fdw/commit/fabea1bfe44bef8831d09e14aa1ca132fdf0e0dc. Please check.