On Fri, 23 Jul 2021 at 16:50, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> OK, I've now studied this more closely, and have some additional
> nitpicks:
>
> * I felt the way you did the documentation was confusing. It seems
> better to explain the normal case first, and then describe the two
> extended cases.
OK, that looks much better. Re-reading the entire section, I think
it's much clearer now.
> * As long as we're encapsulating typmod construction/extraction, let's
> also encapsulate the checks for valid typmods.
Good idea.
> * Other places are fairly careful to declare typmod values as "int32",
> so I think this code should too.
OK, that seems sensible.
> Attached is a proposed delta patch making those changes.
>
> (I made the docs mention that the extension cases are allowed as of v15.
> While useful in the short run, that will look like noise in ten years;
> so I could go either way on whether to do that.)
Hmm, yeah. In general,I find such things in the documentation useful
for quite a few years. I'm regularly looking to see when a particular
feature was added, to see if I can use it in a particular situation.
But eventually, it'll become irrelevant, and I don't know if anyone
will go around tidying these things up. I have left it in, but perhaps
there is a wider discussion to be had about whether we should be doing
that more (or less) often. FWIW, I like the way some docs include an
"available since" tag (e.g,, Java's @since tag).
> If you're good with these, then I think it's ready to go.
> I'll mark it RfC in the commitfest.
Thanks. That all looked good, so I have pushed it.
Regards,
Dean
