Treat `citext` as `String` rather `Opaque` about pg_graphql

[fnimick]

(perhaps a more general solution, in addition to handling citext, would be to allow directives in comments to change the field type as well as the name? that way if we have multiple datatypes that are treated as Opaque by default, we can name them differently and configure a client to map to javascript values in a separate way for each one)

[yatendra2001]

Hey @olirice , I would love to work on this issue. Can you assign this to me??

[olirice]

I agree that citext would be better treated as a String. citext is quite common so if it can be supported easily we'll do it

I'd like to hold off on a generic solution for now, but your comment directive idea sounds pretty solid too

[yatendra2001]

Hi @olirice , so sorry couldn't look up to this issue due to my placement season.

I tried to find citext inside code see but couldn't find it.

I am doing this to trace where exactly unwanted conversion keeps happening.

Can you help?

Also is there any documentation that can help me understand codebase more deeply?

Thanks!!

[olirice]

the best place to start to get onboarded would be the resolve function from there you can follow the whole lifecycle of a request from user input to the response.

The basic steps are

• Load the sql schema (line 48-49)
• Parse the query

  pg_graphql/src/resolve.rs

  Line 14 in 4ac0ca1

  pub fn resolve_inner<'a, T>(

• Resolve selections

  pg_graphql/src/resolve.rs

  Line 127 in 4ac0ca1

  fn resolve_selection_set<'a, 'b, T>(

• Pass the query selections to the relevant builder (Node/Connection/__Type) e.g. top level selections
• Compare the GraphQL schema against the query, parsing arguments, fields etc into a Builder object that contains all the relevant information to transpile a SQL query

  pg_graphql/src/builder.rs

  Line 1359 in 4ac0ca1

  pub fn to_node_builder<'a, T>(

• compile the builder to a SQL statement

  pg_graphql/src/transpile.rs

  Line 1171 in 4ac0ca1

  impl NodeBuilder {

• Execute the SQL statement

  pg_graphql/src/transpile.rs

  Line 72 in 4ac0ca1

  fn execute(&self) -> Result<serde_json::Value, String> {

  pg_graphql/src/resolve.rs

  Line 212 in 4ac0ca1

  Ok(builder) => match builder.execute() {

• Return the result

  pg_graphql/src/resolve.rs

  Line 272 in 4ac0ca1

  GraphQLResponse {

[olirice]

citext will not be referenced anywhere in the code base. You'd have to identify it on the sql Context and manipulate the GraphQL type that it turns into here

pg_graphql/src/graphql.rs

Lines 1624 to 1659 in 4ac0ca1

	fn to_graphql_type(
	&self,
	max_characters: Option<i32>,
	is_set_of: bool,
	schema: &Arc<__Schema>,
	) -> Option<__Type> {
	if is_set_of && !(self.category == TypeCategory::Table) {
	// If a function returns a pseudotype with a single column
	// e.g. table( id int )
	// postgres records that in pg_catalog as returning a setof int
	// we don't support pseudo type returns, but this was sneaking through
	// because it looks like a concrete type
	return None;
	}
	match self.category {
	TypeCategory::Other => {
	Some(match self.oid {
	20 => __Type::Scalar(Scalar::BigInt), // bigint
	16 => __Type::Scalar(Scalar::Boolean), // boolean
	1082 => __Type::Scalar(Scalar::Date), // date
	1184 => __Type::Scalar(Scalar::Datetime), // timestamp with time zone
	1114 => __Type::Scalar(Scalar::Datetime), // timestamp without time zone
	701 => __Type::Scalar(Scalar::Float), // double precision
	23 => __Type::Scalar(Scalar::Int), // integer
	21 => __Type::Scalar(Scalar::Int), // smallint
	700 => __Type::Scalar(Scalar::Float), // real
	3802 => __Type::Scalar(Scalar::JSON), // jsonb
	114 => __Type::Scalar(Scalar::JSON), // json
	1083 => __Type::Scalar(Scalar::Time), // time without time zone
	2950 => __Type::Scalar(Scalar::UUID), // uuid
	1700 => __Type::Scalar(Scalar::BigFloat), // numeric
	25 => __Type::Scalar(Scalar::String(None)), // text
	// char, bpchar, varchar
	18 | 1042 | 1043 => __Type::Scalar(Scalar::String(max_characters)),
	_ => __Type::Scalar(Scalar::Opaque),

[Marviel]

Just ran into this issue -- had a custom text-derived type which cannot be filtered down anymore due to Opaque not having an in operator.

@olirice is there any way to denote that a particular user-defined type should be treated as another postgres type during Filtering operations?

In this case, I'd like to tell pg_graphql "hey, you're safe to treat this like you would a text type"

EDIT: this may be what @yatendra2001 is suggesting

EDIT 2: #402 might solve my use case, as mentioned above. Excited for it!

[olirice]

is there any way to denote that a particular user-defined type should be treated as another postgres type during Filtering operations?

Not currently, and the domains PR wouldn't resolve that problem. Adding support for citext -> String explicitly #418