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@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,
Regards,
Rushabh Lathia
www.EnterpriseDB.com
Attachments:
format_type_fix.patchtext/x-patch; charset=US-ASCII; name=format_type_fix.patchDownload+5-3
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
On Thu, Mar 1, 2018 at 10:10 PM, Tom Lane <tgl@sss.pgh.pa.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