Discussions
Categories
- 196.8K All Categories
- 2.2K Data
- 239 Big Data Appliance
- 1.9K Data Science
- 450.3K Databases
- 221.7K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 550 MySQL Community Space
- 478 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3K ORDS, SODA & JSON in the Database
- 544 SQLcl
- 4K SQL Developer Data Modeler
- 187K SQL & PL/SQL
- 21.3K SQL Developer
- 295.8K Development
- 17 Developer Projects
- 138 Programming Languages
- 292.5K Development Tools
- 107 DevOps
- 3.1K QA/Testing
- 646K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 155 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.1K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 18 Java Essentials
- 160 Java 8 Questions
- 86K Java Programming
- 80 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 204 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 439 LiveLabs
- 38 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 171 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 232 Portuguese
Bug in berkeleydb SQL implementation of custom PRAGMAs

I have found a bug in the implementation of the custom PRAGMAs in the berkeleydb SQLite code.
Specifically, db-18.1.32/lang/sql/adapter/db_pragma.c in the code that configures the output column name for returning the value of a pragma.
As an example, the implementation of the "multiversion" PRAGMA, line 644:
sqlite3VdbeSetColName(v, 0, COLNAME_NAME, zLeft, SQLITE_STATIC)
The use of SQLITE_STATIC implies that the pointer to the column name will be guaranteed valid by the caller. This isn't the case, however, and as a result there is corruption in the column name.
To avoid this, I've managed to patch the code locally changing SQLITE_STATIC to SQLITE_TRANSIENT -- this tells sqlite to make a copy of the string. With this patch, the column name is set correctly and communicated correctly to the code issuing the query.
I hope you can patch this in a subsequent version.