[GH-ISSUE #814] Add `db_prefix` configuration parameter #485

New issue

Closed

opened 2026-02-25 21:35:09 +03:00 by kerem · 3 comments

kerem commented

2026-02-25 21:35:09 +03:00

Owner

Originally created by @ivanov17 on GitHub (Oct 30, 2023).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/814

Originally assigned to: @IrAlfred on GitHub.

🚀 Feature

Hello! I didn't find a parameter for database table name prefix in the Cypht configuration.

It may seem that this is not relevant today, and no one shares the database between several applications anymore. But I remember that such a parameter can also be used to access PostgreSQL schemas other than public. I think this is more widely practiced than sharing MySQL/MariaDB databases.

Design, Layout, Architecture

I think this should be an optional parameter that can be used to access prefixed MySQL/MariaDB database tables or non-default PostgreSQL schemas.

Originally created by @ivanov17 on GitHub (Oct 30, 2023). Original GitHub issue: https://github.com/cypht-org/cypht/issues/814 Originally assigned to: @IrAlfred on GitHub. ## 🚀 Feature  Hello! I didn't find a parameter for database table name prefix in the Cypht configuration. It may seem that this is not relevant today, and no one shares the database between several applications anymore. But I remember that such a parameter can also be used to access PostgreSQL schemas other than `public`. I think this is more widely practiced than sharing MySQL/MariaDB databases. ### Design, Layout, Architecture   I think this should be an optional parameter that can be used to access prefixed MySQL/MariaDB database tables or non-default PostgreSQL schemas.

kerem closed this issue

2026-02-25 21:35:09 +03:00

kerem commented

2026-02-25 21:35:09 +03:00

Author

Owner

@marclaporte commented on GitHub (Nov 4, 2023):

@marclaporte commented on GitHub (Nov 4, 2023): Related: https://github.com/cypht-org/cypht/issues/813

kerem commented

2026-02-25 21:35:09 +03:00

Author

Owner

@marclaporte commented on GitHub (Dec 16, 2025):

@kroky @mose @JohnXLivingston @benoitg

@IrAlfred could work on this. Any thoughts on if and how this should be done?

Would this help for Cypht as a webmail for hosting companies? (When most historically use Roundcube)

@marclaporte commented on GitHub (Dec 16, 2025): @kroky @mose @JohnXLivingston @benoitg @IrAlfred could work on this. Any thoughts on if and how this should be done? Would this help for Cypht as a webmail for hosting companies? (When most historically use Roundcube)

kerem commented

2026-02-25 21:35:09 +03:00

Author

Owner

@benoitg commented on GitHub (Dec 16, 2025):

I doubt it would help any hosting scenarios.

Table prefixes to access postgres namespace is really a confusion caused by mysql doing things different from everyone else (what mysql calls databases is more or less what other database call schemas or namespaces). A prefix with a dot can be used to access a different postgres namespace can also be used to access a different mysql database. Which is equally pointless most of the time.

There is really no reason I can see (besides being needlessly quirky) for a PostgreSQL admin to create a non default schema rather than a postgres database for cypth.

I never really understood the point of user-configured table prefixes (I really don't like db_prefix as a name). Prefixes in generally are useful to share a namespace with other things and not have clashes (I don't know how we handle it in tiki). But that's usually for one of two reasons:

To re-use the credentials of a user that doesn't have permission to create another namespace/database (most frequent, although not that frequent). And not really needed since cypth already has a "hm_" prefix (not very recognizable, but should be enough not to clash)
For the systems to interact through the database (doesn't seem to be the case here)

In both cases, a user prefix is only necessary if the system doesn't already have a prefix unlikely to clash. Cypht doesn't seem to have this problem

A system may also use prefixes to manage multiple copies of itself, or integration testing, but that's never managed by the user.

@benoitg commented on GitHub (Dec 16, 2025): I doubt it would help any hosting scenarios. Table prefixes to access postgres namespace is really a confusion caused by mysql doing things different from everyone else (what mysql calls databases is more or less what other database call schemas or namespaces). A prefix with a dot can be used to access a different postgres namespace can also be used to access a different mysql database. Which is equally pointless most of the time. There is really no reason I can see (besides being needlessly quirky) for a PostgreSQL admin to create a non default schema rather than a postgres database for cypth. I never really understood the point of user-configured table prefixes (I really don't like db_prefix as a name). Prefixes in generally are useful to share a namespace with other things and not have clashes (I don't know how we handle it in tiki). But that's usually for one of two reasons: 1. To re-use the credentials of a user that doesn't have permission to create another namespace/database (most frequent, although not that frequent). And not really needed since cypth already has a "hm_" prefix (not very recognizable, but should be enough not to clash) 2. For the systems to interact through the database (doesn't seem to be the case here) In both cases, a user prefix is only necessary if the system doesn't already have a prefix unlikely to clash. Cypht doesn't seem to have this problem A system may also use prefixes to manage multiple copies of itself, or integration testing, but that's never managed by the user.