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
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!
The text was updated successfully, but these errors were encountered:
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.unit_prefixes
andunit_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.)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."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!
The text was updated successfully, but these errors were encountered: