PostgreSQL support

[iWantToKeepAnon]

I pulled as much database specific code as I found into "includes/class-<mysql|pgsql>.php". I removed the mysql specific backtick syntax everywhere I could (mysql will work w/o it and psql won't work with it). I hacked "docker-entrypoint.sh" over on the docker project (another PR there).

To install pgsql and create the database if pgsql is selected (see "stack.yml" and "stack-pgsql.yml" and "start.bash"). There needs to be a good database selector mechanism, for now I run:

• cd users && ln -s ../includes/class-pgsql.php ./db.php

and that selects postgress. I have not touched the test cases.

[ozh]

Regarding postgresql : the goal here should be to make things compatible with a PGSQL plugin (or other DB engine as you mention) but I don't want to include PGSQL code. Two simple reasons:

• 95% of people don't care about pgsql
• I don't use psql so I won't maintain this code :)

Removing the backticks wrapping column names shouldn't be problematic (it's all hard coded), however we need them around table names : MySQL needs backticks for table names with a dash (eg joe-yourls), see for instance #2844. Maybe a helper function, similar to your dt_year(), with something like:

public function get_tablename($table) {
    return yourls_apply_filter('get_tablename', "`$table`");
}

so it's easy for a PSQL/SQLITE/etc plugin to hook into this and remove backticks

[ozh]

Other things to consider : as far as I understand it the upgrade functions too would need complete rewriting

[iWantToKeepAnon]

Other things to consider : as far as I understand it the upgrade functions too would need complete rewriting

Yes, or just kept separate like the db code is. Chose which upgrade module to use on whatever DB flag gets worked out. And since pgsql is brand new, no old migration code support necessary.

[iWantToKeepAnon]

MySQL needs backticks for table names with a dash (eg joe-yourls)

Ah, ok. The yourls containers for mysql work with this PR but I doubt I had dashes in table names.

[FrankDupree]

Regarding postgresql : the goal here should be to make things compatible with a PGSQL plugin (or other DB engine as you mention) but I don't want to include PGSQL code. Two simple reasons:

• 95% of people don't care about pgsql
• I don't use psql so I won't maintain this code :)

@ozh I really don't agree with point number 1. Postgres really is a robust and popular database. its a shame its not supported by default. and saying something like "I dont use psql so I wont maintain this code" is discouraging. its open source bro, everyone is invited and everyone can help maintain it. @iWantToKeepAnon well done for the effort. you still the man @ozh 💯

[iWantToKeepAnon]

• 95% of people don't care about pgsql
• I don't use psql so I won't maintain this code :)

@FrankDupree, thanks for commenting. And sorry I haven't had time to resolve the conflict put on the pr.

@ozh:

#1: they don't care b/c it isn't available #2: I didn't either until the pain of switching from mysql was greater than the pain of mysql. pgsql is a much more competent and consistent db engine.

I wrote the pr b/c I didn't want to maintain 2 db servers and my main project was experiencing too much mysql pain to stay put.

[FrankDupree]

@iWantToKeepAnon since you have lots of experience with this service, what other alternatives could you recommend, im looking at polr or shlink which would you go for?

[iWantToKeepAnon]

@iWantToKeepAnon since you have lots of experience with this service, what other alternatives could you recommend, im looking at polr or shlink which would you go for?

I am far from an expert on url shorteners. But looking at the 2:

a) polr only lists mysql as a database, so no change there b) shlink lists pgsql so that seems to meet your desired db platform; I like the command line interface idea too

I am satisfied with my pgsql plugin/patch for the moment. It would be nice for it to be in the core product to stay current.

[ozh]

Instead of rewriting things and pulling hair to make queries compatible with pgsql, I think a much simpler option would be to use a query builder, such as https://github.com/auraphp/Aura.SqlQuery/ , to write queries independently from the SQL engine. Then, a one liner plugin would be enough to use pgsql, sqlite or whatever.

[iWantToKeepAnon]

... to write queries independently from the SQL engine. Then, a one liner plugin would be enough to use pgsql, sqlite or whatever.

True, that's a big update but I think the freedom of choice payoff would be bigger.