add support for new naming scheme username@package

[imor]

What kind of change does this PR introduce?

feature

What is the current behavior?

Packages are named username-package, e.g. kiwicopple-pg_idkit.

What is the new behavior?

Packages will be named user@package, e.g. kiwicopple@pg_idkit. Packages published after this change is rolled out can only be installed with new names. Packages published before can still be installed with older naming scheme for compatibility with older dbdev clients. dbdev clients older than 0.0.5 will not be able to install old packages with the new naming scheme. dbdev 0.0.5 (added in this PR) can install all packages with the new naming scheme.

Additional context

N/A

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
dbdev	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 5, 2024 5:16am

[imor]

The @ makes the new naming scheme feel backwards, maybe because of similarity to email ids. Should the naming scheme be changed to package@username?

[olirice]

not for this PR, but we do need to figure out how to deploy clients without baking in the anon key.

[tiniscule]

Sorry to chime in here, but when you say packages can be installed using the old way if they existed prior, does that mean that basejump_core would always be installed as basejump-basejump_core, or would it just always work as both?

It's only important because you can't change the installed package name without data loss as far as I know, so just creates a split flow for new/old users of an extension.

[imor]

Sorry to chime in here, but when you say packages can be installed using the old way if they existed prior, does that mean that basejump_core would always be installed as basejump-basejump_core, or would it just always work as both?

It would work as both for now but the old naming scheme is soft-deprecated by e.g. only showing the new scheme on database.dev. If someone installs using basejump-basejump_core as the name, they can only switch to basejump@basejump_core if they drop and uninstall the extension named basejump-basejump_core and reinstall the new basejump@basejump_core extension.

It's only important because you can't change the installed package name without data loss as far as I know, so just creates a split flow for new/old users of an extension.

If by data loss you mean that the extension needs to be reinstalled then this is true but I don't see a way around Postgres treating the two naming schemes as different extensions. So even though the following two will install the exact same extension in terms of the functionality, they are different extensions as far as Postgres is concerned:

1. create extension "basejump-basejump_core" version '0.0.1';
2. create extension "basejump@basejump_core" version '0.0.1';

Since dbdev is still not 1.0 this is the right time to make this change. Thoughts?

[tiniscule]

Yeah, understand the thinking on your end, just wondering about the words "soft deprecated" and "for now" and what those mean longer term.

I ask because basejump is used in my own projects as well, and if it won't be supported with the current install path I'll need to figure out a way to both migrate my own projects to the new format as well as any users. Since it installs tables/functions used for auth/billing, would just be important for me to find a way to do it smoothly.

Do you intend on maintaining the old install path indefinitely or should I figure it out sooner than later?

[imor]

Do you intend on maintaining the old install path indefinitely or should I figure it out sooner than later?

We intend to keep only the new naming scheme in the long term, so it's better if you could upgrade sooner rather than later. Would something like the following work for you for upgrading without downtime to the extension with the new naming scheme?:

-- start a transaction
begin;

-- drop extension with old naming scheme
drop extension "basejump-basejump_core";
-- uninstall extension with old naming scheme
select pgtle.uninstall_extension('basejump-basejump_core');

-- install extension with new naming scheme
select dbdev.install('basejump@basejump_core');
-- create extension with new naming scheme
create extension "basejump@basejump_core";

-- commit the transaction
commit;

[tiniscule]

I'll give it a shot, but I'm pretty sure that'll result in all the tables created by basejump-basejump_core being deleted and then identical empty tables being created by basejump@basejump_core.

Will play around with options now that I know it's deprecating. Thanks for the quick responses.

[imor]

I'll give it a shot, but I'm pretty sure that'll result in all the tables created by basejump-basejump_core being deleted and then identical empty tables being created by basejump@basejump_core.

Will play around with options now that I know it's deprecating. Thanks for the quick responses.

You are right, data in objects created by a TLE will need to be migrated manually.