Модуль sqlite

2.6. Self-Altering Code

Some opcodes are self-altering. For example, the opcode (which is always the first opcode in every bytecode program) increments its P1 operand. Subsequent opcodes compare their P1 operands to the P1 value for the opcode in order to determine if the one-time initialization code that follows should be skipped. Another example is the opcode which converts its P4 operand from UTF-8 into the correct database string encoding, then converts itself into a opcode.

3. Viewing The Bytecode

Every SQL statement that SQLite interprets results in a program for the virtual machine. But if the SQL statement begins with the keyword EXPLAIN the virtual machine will not execute the program. Instead, the instructions of the program will be returned, one instruction per row, like a query result. This feature is useful for debugging and for learning how the virtual machine operates. For example:

Any application can run an EXPLAIN query to get output similar to the above. However, indentation to show the loop structure is not generated by the SQLite core. The command-line shell contains extra logic for indenting loops. Also, the «comment» column in the EXPLAIN output is only provided if SQLite is compiled with the options.

When SQLite is compiled with the compile-time option, extra commands are available that are useful for debugging and for exploring the operation of the VDBE. For example the pragma can be enabled to cause a disassembly of each VDBE opcode to be printed on standard output as the opcode is executed. These debugging pragmas include:

4. The Opcodes

There are currently 175 opcodes defined by the virtual machine. All currently defined opcodes are described in the table below. This table was generated automatically by scanning the source code from the file vdbe.c.

Remember: The VDBE opcodes are not part of the interface definition for SQLite. The number of opcodes and their names and meanings change from one release of SQLite to the next. The opcodes shown in the table below are valid for SQLite version 3.33.0 check-in fca8dc8b578f2 dated 2020-08-14.


SQLite 3.10.0

6 января 2015 года состоялся релиз SQLite 3.10.0, оформленной в виде подключаемой библиотеки.

Основные изменения

  • Обеспечена возможность использования операторов LIKE, GLOB и REGEXP с виртуальными таблицами;
  • В утилиту sqldiff добавлена опция «—transaction»;
  • Реализованы новые интерфейсы sqlite3_db_cacheflush() и sqlite3_strlike();
  • При открытии символической ссылки на БД, обеспечивающие журналирование файлы теперь создаются в привязке к реальному имени файла, а не имени символической ссылки;
  • При использовании ввода/вывода с применением отображения в память (memory-mapped I/O), отображение теперь производится в режиме только на чтение, что не даёт возможности случайно изменить БД в случае переполнения буфера в приложении или проблем с указателями;
  • В расширение для работы с форматом JSON добавлены новые SQL-функции json_group_array() и json_group_object();
  • Добавлена сборочная опция SQLITE_LIKE_DOESNT_MATCH_BLOBS;
  • Внесена оптимизация производительности, ускорившая работу с БД на 2-3%;
  • В интерфейс командной строки добавлены новые команды «.changes ON|OFF» и «.vfsinfo».

SQLite 3.8.11

30 июля 2015 года стало известно о публикации релиза SQLite 3.8.11.

Вслед за ним вышел корректирующий релиз для легковесной системы управления базами данных, оформленной в виде подключаемой библиотеки.

Тестирование нагрузки SQLite на ЦП, 2015

В новом релизе:

  • Добавлено экспериментальное расширение RBU (Resumable Bulk Update), предназначенное для организации быстрых инкрементальных обновлений больших наборов данных;
  • Добавлено экспериментальное расширение FTS5 с новой реализацией системы полнотекстового поиска;
  • В расширение spellfix1 добавлена поддержка выражения «ON CONFLICT»;
  • В операторе «IS» реализована возможность использования индексов;
  • Улучшена работа планировщика запросов в плане автоматической индексации подзапросов, заданных в блоке FROM;
  • Добавлена команда «PRAGMA cell_size_check» для выявления повреждения файла БД на ранней стадии;
  • В полнотекстовом движке FTS3 в функции matchinfo() появился новый флаг сопоставления «b»;
  • Добавлена программа fuzzcheck для качественного fuzz-тестирования БД. Программа автоматически вызывается при выполнении «make test»;
  • Увеличена эффективность работы страничного кэша и реализовано предварительное выделение памяти для кэша. В тестах изменение позволило поднять производительность на 5% при типовых применения СУБД. Внесены разнообразные микрооптимизации, которые позволили выполнить на 22.3% больше работы в рамках тех же циклов CPU. В сумме, по производительности выпуск 3.8.11 в два раза быстрее 3.8.0 и в три раза быстрее 3.3.9 (при тестировании cachegrind и speedtest1.c в Ubuntu 14.04 x64 при сборке в gcc 4.8.2 с флагом -Os).

Software Licenses

The SQLite source code is in the public domain, and is free for use by anyone and for any purpose. No license is required. However, some users desire a license so that they can have warranty of title, or just because their company lawyers say they need one. A perpetual license and warranty of title for the core SQLite source code is available for this purpose.

The SQLite Encryption Extension (SEE), the ZIPVFS Extension, and the Compressed and Encrypted ReadOnly Database (CEROD) extension are enhanced versions of SQLite that handle encrypted and/or compressed databases. SEE can read and write encrypted databases. SEE encrypts all database content, including metadata, so that the database file appears as white noise. ZIPVFS compresses the database on-the-fly using application-supplied compression and decompression functions. CEROD reads a compressed database that is also optionally encrypted. All of SEE, ZIPVFS, and CEROD are supplied in source code form only; the licensee is responsible for compiling the products for their chosen platform. It is not difficult to compile any of these extension. All products come in the form of an amalgamated source file named «sqlite3.c». So compiling SEE, ZIPVFS, or CEROD into an application is simply a matter of substituting the SEE-, ZIPVFS-, or CEROD-enabled sqlite3.c source file in place of the public-domain sqlite3.c source file and recompiling. Licenses for SEE, ZIPVFS, and CEROD are perpetual. All three extension can read and write ordinary, uncompressed and unencrypted database files.

Situations Where A Client/Server RDBMS May Work Better

  • Client/Server Applications

    If there are many client programs sending SQL to the same database over a network, then use a client/server database engine instead of SQLite. SQLite will work over a network filesystem, but because of the latency associated with most network filesystems, performance will not be great. Also, file locking logic is buggy in many network filesystem implementations (on both Unix and Windows). If file locking does not work correctly, two or more clients might try to modify the same part of the same database at the same time, resulting in corruption. Because this problem results from bugs in the underlying filesystem implementation, there is nothing SQLite can do to prevent it.

    A good rule of thumb is to avoid using SQLite in situations where the same database will be accessed directly (without an intervening application server) and simultaneously from many computers over a network.

  • High-volume Websites

    SQLite will normally work fine as the database backend to a website. But if the website is write-intensive or is so busy that it requires multiple servers, then consider using an enterprise-class client/server database engine instead of SQLite.

  • Very large datasets

    An SQLite database is limited in size to 281 terabytes (247 bytes, 128 tibibytes). And even if it could handle larger databases, SQLite stores the entire database in a single disk file and many filesystems limit the maximum size of files to something less than this. So if you are contemplating databases of this magnitude, you would do well to consider using a client/server database engine that spreads its content across multiple disk files, and perhaps across multiple volumes.

  • High Concurrency

    SQLite supports an unlimited number of simultaneous readers, but it will only allow one writer at any instant in time. For many situations, this is not a problem. Writers queue up. Each application does its database work quickly and moves on, and no lock lasts for more than a few dozen milliseconds. But there are some applications that require more concurrency, and those applications may need to seek a different solution.

DELETE Operation

Following C code segment shows how you can use DELETE statement to delete any record and then fetch and display the remaining records from the COMPANY table.

#include <stdio.h>
#include <stdlib.h>
#include <sqlite3.h> 

static int callback(void *data, int argc, char **argv, char **azColName) {
   int i;
   fprintf(stderr, "%s: ", (const char*)data);
   for(i = 0; i<argc; i++) {
      printf("%s = %s\n", azColName, argv ? argv : "NULL");
   return 0;

int main(int argc, char* argv[]) {
   sqlite3 *db;
   char *zErrMsg = 0;
   int rc;
   char *sql;
   const char* data = "Callback function called";

   /* Open database */
   rc = sqlite3_open("test.db", &db);
   if( rc ) {
      fprintf(stderr, "Can't open database: %s\n", sqlite3_errmsg(db));
   } else {
      fprintf(stderr, "Opened database successfully\n");

   /* Create merged SQL statement */
   sql = "DELETE from COMPANY where ID=2; " \
         "SELECT * from COMPANY";

   /* Execute SQL statement */
   rc = sqlite3_exec(db, sql, callback, (void*)data, &zErrMsg);
   if( rc != SQLITE_OK ) {
      fprintf(stderr, "SQL error: %s\n", zErrMsg);
   } else {
      fprintf(stdout, "Operation done successfully\n");
   return 0;

When the above program is compiled and executed, it will produce the following result.

Opened database successfully
Callback function called: ID = 1
NAME = Paul
AGE = 32
ADDRESS = California
SALARY = 20000.0

Callback function called: ID = 3
NAME = Teddy
AGE = 23
ADDRESS = Norway
SALARY = 20000.0

Callback function called: ID = 4
NAME = Mark
AGE = 25
ADDRESS = Rich-Mond
SALARY = 65000.0

Operation done successfully

Previous Page Print Page

Next Page  

Исключения SQLite3

Исключением являются ошибки времени выполнения скрипта. При программировании на Python все исключения являются экземплярами класса производного от BaseException.

В SQLite3 у есть следующие основные исключения Python:


Любая ошибка, связанная с базой данных, вызывает ошибку DatabaseError.


IntegrityError является подклассом DatabaseError и возникает, когда возникает проблема целостности данных, например, когда внешние данные не обновляются во всех таблицах, что приводит к несогласованности данных.


Исключение ProgrammingError возникает, когда есть синтаксические ошибки или таблица не найдена или функция вызывается с неправильным количеством параметров / аргументов.


Это исключение возникает при сбое операций базы данных, например, при необычном отключении. Не по вине программиста.


При использовании некоторых методов, которые не определены или не поддерживаются базой данных, возникает исключение NotSupportedError.

9.1. Export to Excel

To simplify export to a spreadsheet, the CLI provides the «.excel» command which captures the output of a single query and sends that output to the default spreadsheet program on the host computer. Use it like this:

sqlite> .excel
sqlite> SELECT * FROM tab;

The command above writes the output of the query as CSV into a temporary file, invokes the default handler for CSV files (usually the preferred spreadsheet program such as Excel or LibreOffice), then deletes the temporary file. This is essentially a short-hand method of doing the sequence of «.csv», «.once», and «.system» commands described above.

The «.excel» command is really an alias for «.once -x». The -x option to .once causes it to writes results as CSV into a temporary file that is named with a «.csv» suffix, then invoke the systems default handler for CSV files.

There is also a «.once -e» command which works similarly, except that it names the temporary file with a «.txt» suffix so that the default text editor for the system will be invoked, instead of the default spreadsheet.

10. Accessing ZIP Archives As Database Files

In addition to reading and writing SQLite database files, the sqlite3 program will also read and write ZIP archives. Simply specify a ZIP archive filename in place of an SQLite database filename on the initial command line, or in the «.open» command, and sqlite3 will automatically detect that the file is a ZIP archive instead of an SQLite database and will open it as such. This works regardless of file suffix. So you can open JAR, DOCX, and ODP files and any other file format that is really a ZIP archive and SQLite will read it for you.

A ZIP archive appears to be a database containing a single table with the following schema:

  name,     // Name of the file
  mode,     // Unix-style file permissions
  mtime,    // Timestamp, seconds since 1970
  sz,       // File size after decompression
  rawdata,  // Raw compressed file data
  data,     // Uncompressed file content
  method    // ZIP compression method code

So, for example, if you wanted to see the compression efficiency (expressed as the size of the compressed content relative to the original uncompressed file size) for all files in the ZIP archive, sorted from most compressed to least compressed, you could run a query like this:

sqlite> SELECT name, (100.0*length(rawdata))/sz FROM zip ORDER BY 2;

Or using , you can extract elements of the ZIP archive:

sqlite> SELECT writefile(name,content) FROM zip
   ...> WHERE name LIKE 'docProps/%';

3.1. Determination Of Column Affinity

The affinity of a column is determined by the declared type of the column, according to the following rules in the order shown:

  1. If the declared type contains the string «INT» then it is assigned INTEGER affinity.

  2. If the declared type of the column contains any of the strings «CHAR», «CLOB», or «TEXT» then that column has TEXT affinity. Notice that the type VARCHAR contains the string «CHAR» and is thus assigned TEXT affinity.

  3. If the declared type for a column contains the string «BLOB» or if no type is specified then the column has affinity BLOB.

  4. If the declared type for a column contains any of the strings «REAL», «FLOA», or «DOUB» then the column has REAL affinity.

  5. Otherwise, the affinity is NUMERIC.

Note that the order of the rules for determining column affinity is important. A column whose declared type is «CHARINT» will match both rules 1 and 2 but the first rule takes precedence and so the column affinity will be INTEGER.

3.1.1. Affinity Name Examples

The following table shows how many common datatype names from more traditional SQL implementations are converted into affinities by the five rules of the previous section. This table shows only a small subset of the datatype names that SQLite will accept. Note that numeric arguments in parentheses that following the type name (ex: «VARCHAR(255)») are ignored by SQLite — SQLite does not impose any length restrictions (other than the large global limit) on the length of strings, BLOBs or numeric values.

Note that a declared type of «FLOATING POINT» would give INTEGER affinity, not REAL affinity, due to the «INT» at the end of «POINT». And the declared type of «STRING» has an affinity of NUMERIC, not TEXT.

Анализ поисковых запросов сайта

Приведённый выше отчёт по частотности использования поисковых запросов, может быть использован оптимизаторами сайта при составлении его семантического ядра и подготовке контента т.н. «посадочных страниц». Статистика поисковых запросов — обобщённая сгруппированная информация по «обращениям» пользователей к поисковой системе по ключевым запросам (фразам). В большинстве случаев, наш сервис показывает уже сгруппированную информацию, содержащую не только подборку самых популярных слов (фраз), но и словосочетания + синонимы. Собранная в данном разделе статистика показывает по каким «ключевым словам» (поисковым запросам) пользователи переходят на сайт sqlitestudio.pl.

Поисковый запрос – это слово или словосочетание, которое пользователь вводит в форму поиска на сайте поисковой системы, с учётом автоподбора и автоматического исправления в поиске ошибочного набора.

Further Information

SQLite is free and works great. Most people use SQLite without any kind of license or support.

Free support for SQLite is available on the public SQLite Forum. The forum is monitored by a large community of experts, including the core SQLite development team, who are able to resolve just about any problems with SQLite that you are likely to have.

Users with more advanced support needs can opt for a Technical Support Agreement. Technical support agreements are customized to the needs of each individual client, but generally include direct telephone support and priority handling of issues and bugs. Guaranteed response time is available as an option. The cost of technical support varies but is generally in the range of $8000 to $35000 per year.

If SQLite is «mission critical» to your company, then you may want to become an SQLite Consortium Member. The SQLite Consortium is a collaboration of companies who sponsor ongoing development of SQLite in exchange for enterprise-level technical support, on-site visits from the SQLite developers, unlimited access to all licensed products, and strong guarantees that SQLite will remain in the public domain, free and independent, and will not come under the control of a competitor.


First create a directory in which to place the build products. It is recommended, but not required, that the build directory be separate from the source directory. Cd into the build directory and then from the build directory run the configure script found at the root of the source tree. Then run «make».

For example:

See the makefile for additional targets.

The configure script uses autoconf 2.61 and libtool. If the configure script does not work out for you, there is a generic makefile named «Makefile.linux-gcc» in the top directory of the source tree that you can copy and edit to suit your needs. Comments on the generic makefile show what changes are needed.

SQLite Is Public Domain

SQLite is in thePublic Domain

All of the code and documentation in SQLite has been dedicated to the public domain by the authors. All code authors, and representatives of the companies they work for, have signed affidavits dedicating their contributions to the public domain and originals of those signed affidavits are stored in a firesafe at the main offices of Hwaci. Anyone is free to copy, modify, publish, use, compile, sell, or distribute the original SQLite code, either in source code form or as a compiled binary, for any purpose, commercial or non-commercial, and by any means.

The previous paragraph applies to the deliverable code and documentation in SQLite — those parts of the SQLite library that you actually bundle and ship with a larger application. Some scripts used as part of the build process (for example the «configure» scripts generated by autoconf) might fall under other open-source licenses. Nothing from these build scripts ever reaches the final deliverable SQLite library, however, and so the licenses associated with those scripts should not be a factor in assessing your rights to copy and use the SQLite library.

All of the deliverable code in SQLite has been written from scratch. No code has been taken from other projects or from the open internet. Every line of code can be traced back to its original author, and all of those authors have public domain dedications on file. So the SQLite code base is clean and is uncontaminated with licensed code from other projects.

Connect To Database

Following C code segment shows how to connect to an existing database. If the database does not exist, then it will be created and finally a database object will be returned.

#include <stdio.h>
#include <sqlite3.h> 

int main(int argc, char* argv[]) {
   sqlite3 *db;
   char *zErrMsg = 0;
   int rc;

   rc = sqlite3_open("test.db", &db);

   if( rc ) {
      fprintf(stderr, "Can't open database: %s\n", sqlite3_errmsg(db));
   } else {
      fprintf(stderr, "Opened database successfully\n");

Now, let’s compile and run the above program to create our database test.db in the current directory. You can change your path as per your requirement.

$gcc test.c -l sqlite3
Opened database successfully

If you are going to use C++ source code, then you can compile your code as follows −

$g++ test.c -l sqlite3

Here, we are linking our program with sqlite3 library to provide required functions to C program. This will create a database file test.db in your directory and you will have the following result.

-rwxr-xr-x. 1 root root 7383 May 8 02:06 a.out
-rw-r--r--. 1 root root  323 May 8 02:05 test.c
-rw-r--r--. 1 root root    0 May 8 02:06 test.db

Warranty of Title

SQLite is in the public domain and does not require a license. Even so, some organizations want legal proof of their right to use SQLite. Circumstances where this occurs include the following:

  • Your company desires indemnity against claims of copyright infringement.
  • You are using SQLite in a jurisdiction that does not recognize the public domain.
  • You are using SQLite in a jurisdiction that does not recognize the right of an author to dedicate their work to the public domain.
  • You want to hold a tangible legal document as evidence that you have the legal right to use and distribute SQLite.
  • Your legal department tells you that you have to purchase a license.

If any of the above circumstances apply to you, Hwaci, the company that employs all the developers of SQLite, will sell you a Warranty of Title for SQLite. A Warranty of Title is a legal document that asserts that the claimed authors of SQLite are the true authors, and that the authors have the legal right to dedicate the SQLite to the public domain, and that Hwaci will vigorously defend against challenges to those claims. All proceeds from the sale of SQLite Warranties of Title are used to fund continuing improvement and support of SQLite.

2019: Возможность взлома iPhone через уязвимости в SQLite

16 августа 2019 года стало известно, что специалисты компании Check Point продемонстрировали, как можно взломать iPhone через ядро базы данных, которое использует iOS — SQLite. В этом случае хакеры смогут получить права администратора над устройством.

SQLite — распространенные базы данных. Они доступны в любой операционной системе, персональном компьютере и на мобильном телефоне. Пользователи SQLite — Windows 10, MacOS, iOS, Chrome, Safari, Firefox и Android. Контакты на вашем iPhone, некоторые из сохраненных паролей на вашем ноутбуке — вся эта информация c большой вероятностью хранится в базе данных SQLite.

Специалисты Check Point нашли несколько уязвимостей и изобрели способ их эксплуатации. Проще говоря, теперь стало возможным получение контроля над всем, что обращается к базам данных SQLite.

Так как SQLite является одним из наиболее широко распространенных компонентов программного обеспечения, подобные уязвимости можно применять бесконечное количество раз.

Исследователи Check Point продемонстрировали эти уязвимости двумя способами. В первом случае инженеры перехватили злоумышленника, который заразил тестируемое устройство популярным вредоносным ПО, известным как «похититель паролей». Когда вредоносная программа забирает сохраненный пароль с зараженного компьютера и отправляет его своему оператору, мы получаем контроль над самим оператором.

Вторая демонстрация была на iPhone, на операционной системе iOS. Специалистам удалось обойти доверенный механизм безопасной загрузки Apple и получить права администратора на последнем iPhone.

SQLite практически встроен практически в любую платформу, поэтому можно сказать, что эксперты едва поцарапали верхушку айсберга, если говорить о потенциале эксплуатации уязвимостей.

Компания Check Point надеется, что данное исследование подтолкнет мировое сообщество по кибербезопасности работать дальше над этими уязвимостями.

Отчёт: география и посещаемость сайта

Отчёт в графической форме показывает объём посещений сайта sqlitestudio.pl, в динамике, с привязкой к географическому размещению активных пользователей данного сайта. Отчёт доступен для сайтов, входящих в TOP-100000 рейтинга Alexa. Для всех остальных сайтов отчёт доступен с некоторыми ограничениями.

Alexa Rank – рейтинговая система оценки сайтов, основанная на подсчете общего количества просмотра страниц и частоты посещений конкретного ресурса. Alexa Rank вычисляется исходя из показателей за три месяца. Число Alexa Rank – это соотношение посещаемости одного ресурса и посещаемости прочих Интернет-порталов, поэтому, чем ниже число Alexa Rank, тем популярнее ресурс.

О продукте

SQLite — облегченная встраиваемая реляционная база данных. Исходный код библиотеки передан в общественное достояние. В 2005 году проект получил награду -O’Reilly Open Source Awards.

SQLite не использует парадигму клиент-сервер, то есть движок SQLite не является отдельно работающим процессом, с которым взаимодействует программа, а предоставляет библиотеку, с которой программа компонуется и движок становится составной частью программы. Таким образом, в качестве протокола обмена используются вызовы функций (API) библиотеки SQLite. Такой подход уменьшает накладные расходы, время отклика и упрощает программу. SQLite хранит всю базу данных (включая определения, таблицы, индексы и данные) в единственном стандартном файле на том компьютере, на котором исполняется программа. Простота реализации достигается за счёт того, что перед началом исполнения транзакции записи весь файл, хранящий базу данных, блокируется; ACID-функции достигаются в том числе за счёт создания файла журнала.

Несколько процессов или потоков могут одновременно без каких-либо проблем читать данные из одной базы. Запись в базу можно осуществить только в том случае, если никаких других запросов в данный момент не обслуживается; в противном случае попытка записи оканчивается неудачей, и в программу возвращается код ошибки. Другим вариантом развития событий является автоматическое повторение попыток записи в течение заданного интервала времени.

В комплекте поставки идёт также функциональная клиентская часть в виде исполняемого файла sqlite3, с помощью которого демонстрируется реализация функций основной библиотеки. Клиентская часть работает из командной строки, позволяет обращаться к файлу БД на основе типовых функций ОС.

Благодаря архитектуре движка возможно использовать SQLite как на встраиваемых системах, так и на выделенных машинах с гигабайтными массивами данных.

16.2. SQLite Archive Extract Command

Extract files from the archive (either to the current working directory or to the directory specified by a —directory option). If there are no arguments following the options all files are extracted from the archive. Or, if there are arguments, they are the names of files to extract from the archive. Any specified directories are extracted recursively. It is an error if any specified files are not part of the archive.

-- Extract all files from the archive in the current "main" db to the
-- current working directory. List files as they are extracted. 
.ar --extract --verbose

-- Extract file "file1" from archive "ar.db" to directory "dir1".
.ar fCx ar.db dir1 file1

Version Control

SQLite sources are managed using the Fossil, a distributed version control system that was specifically designed and written to support SQLite development. The Fossil repository contains the urtext.

If you are reading this on GitHub or some other Git repository or service, then you are looking at a mirror. The names of check-ins and other artifacts in a Git mirror are different from the official names for those objects. The offical names for check-ins are found in a footer on the check-in comment for authorized mirrors. The official check-in name can also be seen in the file in the root of the tree. Always use the official name, not the Git-name, when communicating about an SQLite check-in.

If you pulled your SQLite source code from a secondary source and want to verify its integrity, there are hints on how to do that in the section below.

2.5. Subroutines, Coroutines, and Subprograms

The bytecode engine has no stack on which to store the return address of a subroutine. Return addresses must be stored in registers. Hence, bytecode subroutines are not reentrant.

The opcode stores the current program counter into register P1 then jumps to address P2. The opcode jumps to address P1+1. Hence, every subroutine is associated with two integers: the address of the entry point in the subroutine and the register number that is used to hold the return address.

The opcode swaps the value of the program counter with the integer value in register P1. This opcode is used to implement coroutines. Coroutines are often used to implement subqueries from which content is pulled on an as-needed basis.

Triggers need to be reentrant.

Since bytecode subroutines are not reentrant a different mechanism must be used to implement triggers. Each trigger is implemented using a separate bytecode program with its own opcodes, program counter, and register set. The opcode invokes the trigger subprogram. The instruction allocates and initializes a fresh register set for each invocation of the subprogram, so subprograms can be reentrant and recursive. The opcode is used by subprograms to access content in registers of the calling bytecode program.

3.3. Column Affinity For Views And Subqueries

The «columns» of a VIEW or FROM-clause subquery are really the expressions in the result set of the SELECT statement that implements the VIEW or subquery. Thus, the affinity for columns of a VIEW or subquery are determined by the expression affinity rules above. Consider an example:

The affinity of the v1.x column will be the same as the affinity of t1.b (TEXT), since v1.x maps directly into t1.b. But columns v1.y and v1.z both have no affinity, since those columns map into expression a+c and 42, and expressions always have no affinity.

When the SELECT statement that implements a VIEW or FROM-clause subquery is a then the affinity of each supposed column of the VIEW or subquery will be the affinity of the corresponding result column for one of the individual SELECT statements that make up the compound. However, it is indeterminate which of the SELECT statements will be used to determine affinity. Different constituent SELECT statements might be used to determine affinity at different times during query evaluation. Best practice is to avoid mixing affinities in a compound SELECT.

С этим читают