pgsql/ oc/src/sgml/trigger.sgml rc/backend/acc ...

Поиск
Список
Период
Сортировка
От Tom Lane
Тема pgsql/ oc/src/sgml/trigger.sgml rc/backend/acc ...
Дата
Msg-id 200106010241.f512fam41094@hub.org
обсуждение исходный текст
Список pgsql-committers
CVSROOT:    /home/projects/pgsql/cvsroot
Module name:    pgsql
Changes by:    tgl@hub.org    01/05/31 22:41:36

Modified files:
    doc/src/sgml   : trigger.sgml
    src/backend/access/common: scankey.c
    src/backend/access/index: indexam.c istrat.c
    src/backend/catalog: index.c pg_operator.c
    src/backend/commands: copy.c trigger.c
    src/backend/executor: execMain.c
    src/backend/utils/cache: catcache.c relcache.c
    src/backend/utils/fmgr: fmgr.c
    src/include/access: skey.h
    src/include/commands: trigger.h
    src/include/nodes: execnodes.h
    src/include/utils: rel.h

Log message:
    Clean up some minor problems exposed by further thought about Panon's bug
    report on old-style functions invoked by RI triggers.  We had a number of
    other places that were being sloppy about which memory context FmgrInfo
    subsidiary data will be allocated in.  Turns out none of them actually
    cause a problem in 7.1, but this is for arcane reasons such as the fact
    that old-style triggers aren't supported anyway.  To avoid getting burnt
    later, I've restructured the trigger support so that we don't keep trigger
    FmgrInfo structs in relcache memory.  Some other related cleanups too:
    it's not really necessary to call fmgr_info at all while setting up
    the index support info in relcache entries, because those ScanKeyEntry
    structs are never used to invoke the functions.  This should speed up
    relcache initialization a tiny bit.


В списке pgsql-committers по дате отправления:

Предыдущее
От: Bruce Momjian - CVS
Дата:
Сообщение: pgsql/ /HISTORY oc/src/sgml/release.sgml
Следующее
От: Michael Meskes
Дата:
Сообщение: pgsql/src/interfaces/ecpg ChangeLog preproc/ke ...