Pursuant to the report here:
https://www.postgresql.org/message-id/7d0809ee-6f25-c9d6-8e74-5b2967830...@enterprisedb.com
I tried to test all the built-in functions that take "text" (rather
than "name") arguments representing cataloged objects. I was able
to provoke the same assertion failure in hashname() from these:
regression=# select has_column_privilege('postgres','tenk1',repeat('z',
200),repeat('q', 200));
server closed the connection unexpectedly
regression=# select has_language_privilege('postgres',repeat('y',
200),repeat('z', 200));
server closed the connection unexpectedly
regression=# select has_schema_privilege('postgres',repeat('y',
200),repeat('z', 200));
server closed the connection unexpectedly
regression=# select has_foreign_data_wrapper_privilege('postgres',repeat('y',
200),repeat('z', 200));
server closed the connection unexpectedly
regression=# select has_server_privilege('postgres',repeat('y',
200),repeat('z', 200));
server closed the connection unexpectedly
regression=# select pg_get_serial_sequence('tenk1',repeat('x', 200));
server closed the connection unexpectedly
regression=# select pg_get_object_address('table',array[repeat('x',
200)],array[repeat('y', 200)]);
server closed the connection unexpectedly
(Probably many of the code paths in pg_get_object_address can be made to
crash like this, but I stopped after finding one.)
Fortunately, a non-assert build will not crash like this, it'll just
produce a name-not-found failure.
Quite a lot of other functions that didn't crash produced errors
suggesting that they aren't truncating their inputs to NAMEDATALEN
before doing the lookup. I think this is not expected behavior
either, since direct SQL references to such objects would always
be truncated.
Of the functions that did truncate, there was a remarkable lack
of consistency about whether they produced NOTICEs warning of
the truncation. I'm not as concerned about that, but I wonder
whether we ought to have a uniform policy about it.
So what to do? We could run around and fix these individual cases
and call it good, but if we do, I will bet a very fine dinner that
more such errors will sneak in before long. Seems like we need a
coding convention that discourages just randomly treating a C string
as a valid value of type NAME. Not sure how to get there though.
BTW, I also notice that parse_ident() doesn't truncate the identifiers
it parses. ISTM this is a bad thing; isn't more or less the whole
point of that function to convert a string to a name as the Postgres
parser would do?
Comments?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
