Re: [HACKERS] Re: [DOCS] Re: FE/BE protocol revision patcht

OK, I can change it, but it is not easy. Will take time.

Can we go to int32 on atttypmod? I'll try to break it up into two
sub-fields to implement numeric().

I am planning on stripping out the atttypmod usage for string type input
functions (that third parameter).

That was the wrong end to check, since it is the point at which storage
happens that things really need to be checked. Otherwise, no
validation/verification can happen on expression results, only on
constant input values.

Don't know if ignoring that area makes things any easier for you...

- Tom

OK, I can change it, but it is not easy. Will take time.

Can we go to int32 on atttypmod? I'll try to break it up into two
sub-fields to implement numeric().

I am planning on stripping out the atttypmod usage for string type input
functions (that third parameter).

That was the wrong end to check, since it is the point at which storage
happens that things really need to be checked. Otherwise, no
validation/verification can happen on expression results, only on
constant input values.

Don't know if ignoring that area makes things any easier for you...

I will make that change to whatever the current tree is at the time.
May not do it for a few days or a week, but will do it all at once.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Comments? I am willing to change it.

An int 4 atttypmod should be fine. A bit of overhead perhaps, but
who quibles about a few bytes these days? And, perhaps there is a
use.

Yea, no one commented, so it stays an int2 until someone finds a type
that needs more than a two-byte atttypmod. Right now, it fits the
need.

Well, I didn't comment because I haven't yet worked out the issues. But
I'll go with Bruce's and David's inclination that we should shoehorn
numeric()/decimal() into something like the existing atttypmod field
rather than trying for "the general solution" which btw isn't obvious
how to do.

However, I don't think that 16 bits vs 32 bits is an issue at all
performance-wise, and I'd to see atttypmod go to 32 bits just to give a
little breathing room. I'm already using int32 to send attypmod to the
new char/varchar sizing functions.

OK, I can change it, but it is not easy. Will take time.

Can we go to int32 on atttypmod? I'll try to break it up into two
sub-fields to implement numeric().

btw, anyone know of a package for variable- and large-precision
numerics? I have looked at the GNU gmp package, but it looks to me that
it probably won't fit into the db backend without lots of overhead. Will
probably try to use the int64 package in contrib for now...

- Tom

OK, I have made the change so we now have 32-bit atttypmod fields. We
were already passing it as int32 to the clients, so no changes to libpq.

This change will required all developers to do a new initdb.

I had forgotten how much code there is for atttypmod. I did it in
stages, but forgot how intertwined it is in much of the code. I used a
consistent naming convention, so it was very easy to change all
references very quickly.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)