Closed olirice closed 1 year ago
Would your users find it awkward that all extensions would need to be quoted? Personally, I find it tedious which is why avoid special characters in object names.
For the most part users will be installing packages using the in-database client e.g.
select dbdev.install('oli@foo');
the CLI
dbdev install 'oli@foo' --connection=...
or via dumpable SQL that you can put in a migration file.
so it might not come up all that often. But even so, (imo) the explicitness that comes from quoting is also a positive
Hey @olirice, we merged a change to add @
to the character allowlist. Do you need a new tag with this change?
awesome!
Do you need a new tag with this change?
that'd be very helpful, thank you!
Created a v1.3.1 tag. I'll go ahead and close this issue, thanks for reporting!
Describe the problem
For the dbdev pg_tle package manager, we've adopted a
<username><separator><package_name>
strategy to avoid name squatting. Due to the the pg_tle naming restrictions we've been struggling with finding a goodseparator
that clearly communicates that intent.Currently, we use a single hyphen
-
between<username>
and<package_name>
because it is already permitted e.g.but the consensus seems to be that it is unintuitive for users and doesn't look great.
In a perfect world we'd use
/
, but given the challenges inherent in using things that can be interpreted as file separators that probably isn't the best choice.The one we landed on as a middle ground is
@
.So in short, this ask is for
@
to be added to the character allow list for pg_tle package names so we can use it between author and package names for dbdev. Its purely for aesthetic reasons, but aesthetics can make a big difference to how something feels to use.Example:
If that isn't possible I'd also love to hear any other suggestions you might have around pg_tle naming conventions