Re: change in behaviour for format_type() call

Commit a26116c6cbf4117e8efaa7cfc5bacc887f01517f changed the behaviour
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).

Below are the difference it's making to the query output:

Before commit:

postgres(at)95320=#select format_type('bpchar'::regtype, null);
format_type
-------------
character
(1 row)

postgres(at)95320=#select format_type('bit'::regtype, null);
format_type
-------------
bit
(1 row)

After commit:

postgres(at)90169=#select format_type('bpchar'::regtype, null);
format_type
-------------
bpchar
(1 row)

postgres(at)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,

Regards,
Rushabh Lathia
www.EnterpriseDB.com

Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)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

On Thu, Mar 1, 2018 at 10:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 Tom.

Regards,
Rushabh Lathia
www.EnterpriseDB.com