Return valid_target_types for each column in RPC columns.list

[seancolsen]

In he REST API, I could GET http://localhost:8000/api/db/v0/tables/5796/columns/ and receive a response where each column object had a valid_target_types value that would either be null or an array like this:

[
  "bigint",
  "boolean",
  "character",
  "character varying",
  "date",
  "double precision",
  "integer",
  "interval",
  "json",
  "jsonb",
  "mathesar_types.email",
  "mathesar_types.mathesar_json_array",
  "mathesar_types.mathesar_json_object",
  "mathesar_types.mathesar_money",
  "mathesar_types.multicurrency_money",
  "mathesar_types.uri",
  "money",
  "numeric",
  "real",
  "smallint",
  "text",
  "time with time zone",
  "time without time zone",
  "timestamp with time zone",
  "timestamp without time zone"
]

The front end needs this data for each column. Can we implement it with the columns.list RPC method?

@mathemancer @Anish9901 I've labeled this issue needs: backend approval so that one or both of you can confirm that this makes sense. I don't know if there make have been a good reason for omitting this functionality from the RPC API. Heck, I wouldn't be surprised if I even said we didn't need it at some point (shrug)! But it's pretty clear to me that it's going to be hard to work around this omission in the front end. Were we designing the API from scratch, I could see an argument for putting this data in a separate RPC method. But I think that would be too time consuming on the front end right now.

I need this fixed soon since it's blocking my progress on the table page. Is this something Anish could pick up perhaps?

[mathemancer]

I actually think this fell through the crack between columns.list and columns.metadata.list, since it's kinda metadata that comes from the database rather than the metadata model.

I'll look into it.