sql: capture sequences used in cast exprs

[the-ericwang35]

Previously, GetSequenceFromFunc only looked
for *tree.DString and *tree.DOid. However,
it's also possible for the sequence to be given via
a *tree.CastExpr (for example, nextval('s'::regclass)).
In this case, the sequence was not being captured,
which meant no back references were created and
no sequence encoding was done.
This PR addresses this by adding an additional
case to capture these sequences.

This will probably need to be backported.

Release note: None

[cockroach-teamcity]

This change is 

[ajwerner]

This needs a backport. I worry that there are some other crazy cases where we might wish we had some constant folding that I care a bit less about.

Nice catch. What helped you find this? Is it that in the later PR we actually do serialize them like this?

Reviewable status: complete! 0 of 0 LGTMs obtained

[the-ericwang35]

Thanks for the review!

Nice catch. What helped you find this? Is it that in the later PR we actually do serialize them like this?

It was because while writing the PR for sequences in views, I noticed we didn't allow regclass IDs in views (doing something like CREATE VIEW v AS (SELECT nextval(59::regclass)) results in ERROR: relation "59" does not exist). This code was the reason for this, since it always assumes the value being cast to regclass is a table name (I've since changed this to allow for IDs in the views/sequences PR). This made me realize I never tested this table name regclass case, and lo and behold it didn't work.

[the-ericwang35]

bors r=ajwerner

[craig]

Build succeeded:

• GitHub CI (Cockroach)