feat: support user-defined types in YAML extensions

[kadinrabo]

Support parsing UserDefinedType (denoted by u!) in extension yaml

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 54.53%. Comparing base (002720e) to head (dd2fc7d).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #60      +/-   ##
==========================================
- Coverage   55.32%   54.53%   -0.80%     
==========================================
  Files          35       35              
  Lines        6924     8006    +1082     
==========================================
+ Hits         3831     4366     +535     
- Misses       2896     3441     +545     
- Partials      197      199       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[vbarua]

Looks reasonable to me, but I'm not super familiar with the Go side of things.

cc: @zeroshade, @jacques-n: should be an easy review.

[jacques-n]

I believe @anshuldata is or will be working on a patch to replace the hand parsing with antlr grammar. That should address several gaps in the current function parsing. I'd be inclined to wait until that is merged before trying to solve this gap (as some of it may come for cheap/free).

[vbarua]

@jacques-n do you think that will be available next week? We have some stuff internally that's blocked on us being able to handle user-defined types. Aside from potentially redundant work on our end, would there be any harm in updating the hand parser.

[zeroshade]

@vbarua It's unlikely that something as large as replacing with an antlr grammar will be merged next week as I'm sure that would need significant review and testing. My personal opinion would be that it makes sense to update this if you need it. I doubt there's any harm besides the redundant work.

@jacques-n thoughts?

[jacques-n]

I think this patch is building debt on debt.

In general, I find it to be a bad habit to accept something we know we're going to delete in a couple of weeks (unless we're fixing a critical regression). It sets a bad precedent for new contributors on how we work. If we know we're going in a certain direction and one contributor wants to go there faster than another, let's just have them take us to the target outcome.

I'm -0 on this patch. I'm not going to block.

[kadinrabo]

I honestly agree this PR doesn't really solve much with antlr on the way and isn't a good precedent. Thankfully this is small. Although, I want to keep contributing positively so I'll add this to my personal "developing substrait" notes. At this point I guess I'm just asking for a ✅ out of kindness for a new contributor :) as this would significantly unblock me internally.
cc @zeroshade @jacques-n

[zeroshade]

LGTM assuming that @jacques-n has no objections

[vbarua]

Based on

I'm -0 on this patch. I'm not going to block.

I'm going to merge this in.