Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with function is_empty #340

Open
sjstoelting opened this issue Sep 28, 2024 · 3 comments
Open

Problem with function is_empty #340

sjstoelting opened this issue Sep 28, 2024 · 3 comments

Comments

@sjstoelting
Copy link

The problem is, that another extension, pgsql-tweaks, is installing the function is_empty, but with different returning results, pgtap is returning text, pgsql-tweaks is returning a boolean, please see is_empty source.
In addition the installation of either one might fail, if the other one is already installed.

I can and will solve the problem by changing the name from is_empty to is_empty_b (the b for the boolean result), if pgtap is already installed. But it would not solve the problem to install pgtap, if pgsql-tweaks is installed.

And overwriting each others function might cause problems, as they differ in their returning data type.

Just in case, the pg-tweaks repository on GitHub is only a mirror of the one on GitLab.

@wolfgangwalther
Copy link
Contributor

Just install each extension in their own schema? I always put pgtap into pgtap - and then put that into the search path, when required.

Extensions must really be able to assume their own namespace, they can't expect that no other extension clashes with any of their name.

@sjstoelting
Copy link
Author

That might be true to experienced users, like you and me, but not to most people out there using PostgreSQL and extensions. That is at least my experience from consulting work and support on Telegram channels.

@theory
Copy link
Owner

theory commented Sep 29, 2024

Overwriting each other's functions is a limitation of Postgres extensions. Adding them to different schemas is the only supported solution I'm aware of.

Someday I'd like to see extensions get their own namespaces separate from schemas, but I don't know how do-able it'll be to get it designed, agreed to, and implemented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants