fix: add uuid to duckdb, postgres

[skokenes]

Adds uuid support to DuckDB and Postgres. I believe this fixes #1764 and #1761, but need some manual verification still

[mtoy-googly-moogly]

I do not approve this change. We used to do this, I backed it out when I added unsupported (now called unsupported native sql) types.

This is not "supporting" uuid. This is pretending that a uuid is a string.

I am open to argument about how wrong I am, but I need the argument.

[leandro-hermes]

I don't think (in my poor knowledge) that we need some kind of full support for UUID in Malloy - I don't see any use for this.

But on the other hand, I see benefits in just considering them as string fields, because currently Malloy doesn't allow us to create expressions with unsupported types:

line 4: Unsupported type not allowed in expression
  |   where: id = '6ffae411-6852-4131-9ba9-e022838991b7'
  |          ^ 

The need to cast the field as string causes the database to not properly use the indexes created on these fields, degrading the performance.

[skokenes]

I do not approve this change. We used to do this, I backed it out when I added unsupported (now called unsupported native sql) types.

This is not "supporting" uuid. This is pretending that a uuid is a string.

I am open to argument about how wrong I am, but I need the argument.

Ok. This came across my desk because the legacy renderer isn't showing uuid columns at all, they just disappear in the output tables. I'll look into why. The "Unsupported" renderer is supposed to render the unsupported data type as a string if it can. And it would seem like we should be able to do that with a uuid column, so I'm not sure whats going on there.

[mtoy-googly-moogly]

@leandro-hermes this is a great example, the idea of unsupported native types is newish and we definitely need to listen to people trying to use them and work on them a little

the workaround for that might be to write, (i think)

where: id = '6ffae411-6852-4131-9ba9-e022838991b7'::"uuid"

how does that feel?

[leandro-hermes]

@mtoy-googly-moogly I don't like the idea of casting the string, since we don't need to do this in SQL (at least in PostgreSQL and DuckDB). Since Malloy is supposed to simplify SQL, by adding this, we would hurt this idea.

But, it is not a thing that would make me stop using Malloy at all.