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

Documentation suggestions #39

Open
kengruven opened this issue Jan 22, 2023 · 0 comments
Open

Documentation suggestions #39

kengruven opened this issue Jan 22, 2023 · 0 comments

Comments

@kengruven
Copy link

This looks like a pretty neat extension, but there were several aspects which I couldn't figure out from just the documentation.

  • @ looks like a conversion operator, but I can't guess what some of the other functions/symbols do. I think a lot are standard (if uncommon) Postgres operators which are simply overloaded, but ASCII art is hard to search for in a manual. (I eventually found a couple in the postgresql-unit changelog, and a couple in a third-party Postgres blog article.) The list of Operators and Functions look like they fall into distinct categories: shortcuts for applying a unit (ampere), new unit functionality (unit_at), overridden Postgres functionality (<=), and so on. It might be helpful to group them this way, since you don't need to document each unit application function separately, for example.
  • This extension added tables unit_prefixes and unit_units in my public schema; is it possible to install them in a different place, or move them? (I don't know if this is common practice with Postgres extensions or not. I don't even know if it uses the "public" schema, or the current schema when you run the CREATE EXTENSION command.)
  • It's not clear where the "config" should go. Is this server config, or client config? Is it per-session or per-database or do I need to set it the same globally? I'm also not sure how to query this, or if I might need to make my client program handle these output formats.
  • It might be helpful to suggest using a CHECK constraint (like CHECK dimension(length) = '1 m') on unit-typed columns, since there doesn't appear to be any other way to force a column to have a particular dimension. If someone inserted incompatible data, then querying with < would return nonsensical results, and using << would return an error. Presumably, having consistent data (and simpler queries) would also allow an index to be used more efficiently, too, but I haven't tested this yet.
  • When reading a result set with psycopg, I seem to get data out as a string ("1 kg"), which is fine. Do I need to look up this OID in the schema? I think some Postgres extensions hardcode their OIDs, but I don't see this number in the postgresql-unit source.

Thanks for the nice extension!

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

1 participant