-
-
Notifications
You must be signed in to change notification settings - Fork 290
Open
Description
Let's say I have the really dumb idea of creating a data type with the exact same name that an existing Postgres Type.
mod foo {
use pgrx::prelude::*;
#[derive(PostgresType, Serialize, Deserialize, Debug )]
#[derive(Eq, PartialEq, Ord, Hash, PartialOrd)]
#[derive(PostgresEq)]
#[derive(PostgresOrd)]
#[derive(PostgresHash)]
#[inoutfuncs]
pub struct Text {
// [...]
}
}
The #[derive(PostgresType)]
related entities will be written correctly
CREATE TYPE foo.Text;
CREATE FUNCTION foo."text_lt"(/* .... */)
However the #[derive(PostgresOrd)]
will be written without the schema prefix
CREATE OPERATOR FAMILY Text_btree_ops USING btree;
CREATE OPERATOR CLASS Text_btree_ops DEFAULT FOR TYPE Text USING btree FAMILY Text_btree_ops AS
OPERATOR 1 <,
OPERATOR 2 <=,
OPERATOR 3 =,
OPERATOR 4 >=,
OPERATOR 5 >,
FUNCTION 1 text_cmp(Text, Text)
Which gives the following error:
create extension foo;
ERROR: function text_cmp(text, text) does not exist
My understanding is that the PostgresOrd derived entities should be schema qualified like other entities:
CREATE OPERATOR FAMILY foo.Text_btree_ops USING btree;
CREATE OPERATOR CLASS foo.Text_btree_ops DEFAULT FOR TYPE foo.Text USING btree FAMILY foo.Text_btree_ops AS
OPERATOR 1 <,
OPERATOR 2 <=,
OPERATOR 3 =,
OPERATOR 4 >=,
OPERATOR 5 >,
FUNCTION 1 foo.text_cmp(foo.Text, foo.Text);
See code above:
https://github.com/pgcentralfoundation/pgrx/blob/develop/pgrx-sql-entity-graph/src/postgres_ord/entity.rs#L84
I understand that this a very narrow use case and a good practice is to avoid naming new types with the names of regular Postgres types.
Nonetheless it seems like a good idea to avoid those kind of collisions.
Metadata
Metadata
Assignees
Labels
No labels