You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the code relies heavily on the ‘postgres’ user for table creation and permission handling. In my tests, installing Giswater on databases without a ‘postgres’ user leads to errors.
I would like to suggest that if using the ‘postgres’ user is truly necessary, checks are added to ensure it exists. Where possible, consider replacing ‘postgres’ with a system user (e.g., role_system) or using the ‘current_user’ instead.
This would improve compatibility, especially for managed or hardened PostgreSQL installations where the default superuser may not be named ‘postgres’. My suggestion is set role_system as owner of every object in a Giswater schema. What do you think? May I work in this?
Currently, the code relies heavily on the ‘postgres’ user for table creation and permission handling. In my tests, installing Giswater on databases without a ‘postgres’ user leads to errors.
I would like to suggest that if using the ‘postgres’ user is truly necessary, checks are added to ensure it exists. Where possible, consider replacing ‘postgres’ with a system user (e.g., role_system) or using the ‘current_user’ instead.
This would improve compatibility, especially for managed or hardened PostgreSQL installations where the default superuser may not be named ‘postgres’. My suggestion is set
role_systemas owner of every object in a Giswater schema. What do you think? May I work in this?