BUG #8702: psql \df+ translate_columns[] overflow and unexpected gettext translation
The following bug has been logged on the website:
Bug reference: 8702
Logged by: Sergey Burladyan
Email address: eshkinkot@gmail.com
PostgreSQL version: 9.3.1
Operating system: Debian testing
Description:
I get this result from \df+ foo:
--- echo $LANG
--- ru_RU.UTF-8
---
--- create function foo() returns void language plpgsql as $$ begin end $$;Список функций
-[ RECORD 1
]----------+---------------------------------------------------------------------------------------------------------------------
Схема | public
Имя | foo
Тип данных результата | void
Типы данных аргументов |
Тип | обычная
Безопасность | вызывающего
Изменчивость | volatile
Владелец | seb
Язык | plpgsql
Исходный код | begin end
Описание | Project-Id-Version: PostgreSQL 9 current
| Report-Msgid-Bugs-To: pgsql-bugs@postgresql.org
| POT-Creation-Date: 2013-05-20 02:16+0000
| PO-Revision-Date: 2013-05-20 20:02+0400
| Last-Translator: Alexander Lakhin
<exclusion@gmail.com>
| Language-Team: Russian
<pgtranslation-translators@pgfoundry.org>
| Language: ru
| MIME-Version: 1.0
| Content-Type: text/plain; charset=UTF-8
| Content-Transfer-Encoding: 8bit
| X-Poedit-Language: Russian
| X-Poedit-Country: RUSSIAN FEDERATION
| X-Generator: Lokalize 1.5
| Plural-Forms: nplurals=3; plural=(n%10==1 &&
n%100!=11 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2);
|
looks like "Description" field contains header from ru.mo messages file.
src/bin/psql/describe.c:describeFunctions translate_columns[] array size
is less than the maximum number of columns in query and it overflowed in
src/bin/psql/print.c:printQuery at
...
translate = (opt->translate_columns &&
opt->translate_columns[c]);
...
so in my case opt->translate_columns[10] have garbage == true and
"Description" field
content translated unexpectedly.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Fri, 2013-12-27 at 00:00 +0000, eshkinkot@gmail.com wrote:
I get this result from \df+ foo: --- echo $LANG --- ru_RU.UTF-8 --- --- create function foo() returns void language plpgsql as $$ begin end $$;
src/bin/psql/describe.c:describeFunctions translate_columns[] array size
is less than the maximum number of columns in query and it overflowed in
src/bin/psql/print.c:printQuery at
...
translate = (opt->translate_columns &&
opt->translate_columns[c]);
...
so in my case opt->translate_columns[10] have garbage == true and
"Description" field
content translated unexpectedly.
There are several places that are similarly broken. See attached patch.
Obviously, this is not a very robust programming interface, if the same
mistake has been repeated three times independently.
Attachments:
0001-psql-Fix-translate_columns-counts.patchtext/x-patch; charset=UTF-8; name=0001-psql-Fix-translate_columns-counts.patchDownload+3-7
Peter Eisentraut <peter_e@gmx.net> writes:
There are several places that are similarly broken. See attached patch.
Obviously, this is not a very robust programming interface, if the same
mistake has been repeated three times independently.
Yeah :-(. How about adding an Assert as in the attached?
I had to make the Assert say ">=" not just "==" because there are numerous
callers that use the same array for both normal and verbose output.
This seems a bit shaky but it's not actually broken anywhere.
I think.
The breakage in \df appears to be the fault of the addition of a
translated "security definer/invoker" column, which clearly nobody really
tested the translations for, or they'd have noticed that the column
marking in translate_columns[] was wrong :-(. I believe the "translation
support" in \dy (event triggers) is pretty bogus as well.
regards, tom lane
Attachments:
check-translate-columns-counts.patchtext/x-diff; charset=us-ascii; name=check-translate-columns-counts.patchDownload+27-7
Tom Lane <tgl@sss.pgh.pa.us> writes:
Peter Eisentraut <peter_e@gmx.net> writes:
Obviously, this is not a very robust programming interface, if the same
mistake has been repeated three times independently.
Yeah :-(. How about adding an Assert as in the attached?
I cleaned up the issues in \dy and committed this.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs