|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>|
|Cc:||Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: WIP: Relaxing the constraints on numeric scale|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> All your other suggestions make sense too. Attached is a new version.
OK, I've now studied this more closely, and have some additional
* I felt the way you did the documentation was confusing. It seems
better to explain the normal case first, and then describe the two
* As long as we're encapsulating typmod construction/extraction, let's
also encapsulate the checks for valid typmods.
* Other places are fairly careful to declare typmod values as "int32",
so I think this code should too.
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.)
If you're good with these, then I think it's ready to go.
I'll mark it RfC in the commitfest.
regards, tom lane
|Next Message||vignesh C||2021-07-23 16:01:09||Re: Corrected documentation of data type for the logical replication message formats.|
|Previous Message||Pavel Stehule||2021-07-23 15:42:20||Re: badly calculated width of emoji in psql|