aboutsummaryrefslogtreecommitdiff
path: root/src/interfaces/jdbc
diff options
context:
space:
mode:
authorBruce Momjian <bruce@momjian.us>2000-09-12 04:15:58 +0000
committerBruce Momjian <bruce@momjian.us>2000-09-12 04:15:58 +0000
commit0ba0e321726e02c54c4440282b51f25078fe8d81 (patch)
tree43e9199812be014d8e3a03f84612e0a2e1762bf6 /src/interfaces/jdbc
parentb1777d5f997a4e1c5989c2c7d3be5df447a41614 (diff)
downloadpostgresql-0ba0e321726e02c54c4440282b51f25078fe8d81.tar.gz
postgresql-0ba0e321726e02c54c4440282b51f25078fe8d81.zip
O.K. -
Here's the multibyte aware version of my patch to fix the truncation of the rulename autogenerated during a CREATE VIEW. I've modified all the places in the backend that want to construct the rulename to use the MakeRetrieveViewRuleName(), where I put the #ifdef MULTIBYTE, so that's the only place that knows how to construct a view rulename. Except pg_dump, where I replicated the code, since it's a standalone binary. The only effect the enduser will see is that views with names len(name) > NAMEDATALEN-4 will fail to be created, if the derived rulename clases with an existing rule: i.e. the user is trying to create two views with long names whose first difference is past NAMEDATALEN-4 (but before NAMEDATALEN: that'll error out after the viewname truncation.) In no case will the user get left with a table without a view rule, as the current code does. Ross Reedstrom
Diffstat (limited to 'src/interfaces/jdbc')
0 files changed, 0 insertions, 0 deletions