Thread: change in behaviour for format_type() call
Commit a26116c6cbf4117e8efaa7cfc5bacc
for format_type.
Prior to commit, format_type() used to set typemod_given to false for
typemode = NULL.
format_type()
..
if (PG_ARGISNULL(1))
result = format_type_internal(type_oid, -1, false, true, false);
else
{
typemod = PG_GETARG_INT32(1);
result = format_type_internal(type_oid, typemod, true, true, false);
}
..
With the commit format_type() always set the FORMAT_TYPE_TYPEMOD_GIVEN
flag even when typemode is NULL (-1).
flag even when typemode is NULL (-1).
Below are the difference it's making to the query output:
Before commit:
postgres@95320=#select format_type('bpchar'::regtype, null);
format_type
-------------
character
(1 row)
postgres@95320=#select format_type('bit'::regtype, null);
format_type
-------------
bit
(1 row)
After commit:
postgres@90169=#select format_type('bpchar'::regtype, null);
format_type
-------------
bpchar
(1 row)
postgres@90169=#select format_type('bit'::regtype, null);
format_type
-------------
"bit"
(1 row)
Is this expected behaviour? attaching patch to get back the older
behaviour.
Thanks,
Rushabh Lathia
Attachment
Rushabh Lathia <rushabh.lathia@gmail.com> writes:
> Commit a26116c6cbf4117e8efaa7cfc5bacc887f01517f changed the behaviour
> for format_type.
> ...
> Is this expected behaviour? attaching patch to get back the older
> behaviour.
I don't see anything in the commit message or linked discussion to
indicate that any visible behavior change was intended, so I think
you're right, this is a bug. Will check and push your patch.
regards, tom lane
I wrote:
> I don't see anything in the commit message or linked discussion to
> indicate that any visible behavior change was intended, so I think
> you're right, this is a bug. Will check and push your patch.
Actually, this patch still wasn't quite right: although it fixed
one aspect of the behavior, it still produced identical results
for typemod NULL and typemod -1, which as the function's comment
explains is not what should happen. I tweaked the logic to look
as much as possible like before, and added a regression test.
regards, tom lane
Tom Lane wrote: > I wrote: > > I don't see anything in the commit message or linked discussion to > > indicate that any visible behavior change was intended, so I think > > you're right, this is a bug. Will check and push your patch. > > Actually, this patch still wasn't quite right: although it fixed > one aspect of the behavior, it still produced identical results > for typemod NULL and typemod -1, which as the function's comment > explains is not what should happen. I tweaked the logic to look > as much as possible like before, and added a regression test. Thanks! -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Mar 01, 2018 at 02:54:22PM -0300, Alvaro Herrera wrote: > Tom Lane wrote: >> Actually, this patch still wasn't quite right: although it fixed >> one aspect of the behavior, it still produced identical results >> for typemod NULL and typemod -1, which as the function's comment >> explains is not what should happen. I tweaked the logic to look >> as much as possible like before, and added a regression test. > > Thanks! Thanks Tom. Yes, we focused on not changing any existing behavior with this patch. So this report was a bug. -- Michael
Attachment
On Thu, Mar 1, 2018 at 10:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Regards, I wrote:
> I don't see anything in the commit message or linked discussion to
> indicate that any visible behavior change was intended, so I think
> you're right, this is a bug. Will check and push your patch.
Actually, this patch still wasn't quite right: although it fixed
one aspect of the behavior, it still produced identical results
for typemod NULL and typemod -1, which as the function's comment
explains is not what should happen. I tweaked the logic to look
as much as possible like before, and added a regression test.
Thanks Tom.
Rushabh Lathia