The reason seems to be

having a predefined list of supported types, where everything else is treated as a string. And also

which doesn't support objects.

If the function is immutable, it would be accessible via a GET request, which would probably need to be modeled somehow in Swagger to match query strings like search.event=a&search.pixel_key=b (with each property marked as the appropriate type), and a model supporting POST requests, where the parameters probably would be something like { "search": { "event": "a", "pixel_key": "b", ... } }. Just guessing...

I'd assume what's in your comment should simply be infered from the type. No need for a comment with type definitions.

Regarding your title: I initially thought you meant a Postgres PROCEDURE introduced in v11. Took me a while to figure out you meant your FUNCTION argument type total_user_acquisition_search_type didn't get added correctly.

I have never written a line of Haskell in my life, so I probably can't help you though.

Thanks for the help here @nerfpops. You're right in that we default to a string for unknown pg types.

@fstn I see you want to document the function arguments. As a workaround, perhaps you could COMMENT on the function instead?

Hi @steve-chavez, thank you so much for all the work you put into this project. I see that you renamed the issue, but shouldn't postgrest ideally spit out a schema matching the function signature, even with composite types?

I thought this would be a simple starter issue for learning Haskell, but it seems to not be that easy after all.

I'm trying to figure out how to add type comments in openapi, but to do so, I'm imagining something like the following will have to be done...

Currently, these values are preloaded:

wouldn't it make sense to preload all the types as well, with their comments?

PgType would need to contain all the required information for a type, and no longer just a QualifiedIdentifier

My noob skills in Haskell is going to show it's ugly face here, but to enable us to print comments, and also the type information, PgType would need to look something like this:

data PgTypeDescription = PgTypeDescription {
    ptdSchema :: Text
  , ptdName :: Text
  , ptdDescription :: Maybe Text
} deriving (Eq, Show, Ord)

-- Base type name in Postgres (text/jsonb/uuid/...)
data PgBaseType = Text deriving (Eq, Show, Ord)

data PgType
  = Scalar PgTypeDescription PgBaseType
  | Composite PgTypeDescription [PgType]
  deriving (Eq, Show, Ord)

With [PgType] added to Composite because you can't create composite types without columns.

When preloading types, it must be each and every type in the database, since you can reference any type outside the public schema.

Would this be a viable approach?

Edit: On second thought, I'll probably get in trouble with circular references, if I add [PgType] to Composite. I should stick with

data PgTypeDescription = PgTypeDescription {
    ptdSchema :: Text
  , ptdName :: Text
  , ptdDescription :: Maybe Text
} deriving (Eq, Show, Ord)

data PgType
  = Scalar PgTypeDescription
  | Composite PgTypeDescription
  deriving (Eq, Show, Ord)

@nerfpops Seems like a solid approach.

You'd need to query pg_type first and then convert to Haskell types. A type can be created on a particular schema. At first I was thinking we should only get the exposed db-schema types. But getting all of the db types seems fine.

As a first step it'd be better to focus on getting only the types comments. A nice mapping between the pg type and haskell type could get cumbersome as you mentioned. This could be refined later.