Ulozena procedura je neco, co mas dlouhodobe v databazi (a muze to bejt kuprikladu tvoje jediny API, ostatne takhle nejak funguje tusim KOS). Priklad: PL/SQL (a PL/pgSQL) procedury budes mit ulozeny na databazi.

To co mi prijde ze popisujes je prepared statement, viz http://www.postgresql.org/docs/9.0/static/sql-prepare.html ci http://dev.mysql.com/doc/refman/5.1/en/prepare.html

_{disclaimer: necetl jsem extra pozorne:]}

A teda, neprijde mi ze by "interni" API muselo nezbytne nutne locknout vnitrni reprezentaci. Jak bych si to dovedl predstavit je neco jako:

// generovani
const char* query_template = "Select Name, Surname from Foo join Bar where %1% == %2%";
size_t query_size = database->get_internal_size(query_template);
void* query_compiled = malloc(query_size);
database->compile_query(query_template, query_compiled);

// usage
database->query(query_compiled, DATABASE_STRING, "Name", DATABASE_STRING, "Novak");

Takze by se od databaze zjistilo kolik chce pameti, nechalo ji to predkompilovat query template do nejaky (pro nas transparentni) vnitrni formy, a po hozeni dotazu by se ji dala jednak tahle vnitrni forma, a druhak chybejici parametry.

Chapu ze tahani vnitrni formy mezi procesama (a po siti atd) neni uplne optimalni, proto bych se priklanel spis k tomu, aby si to ten databazovej stroj nechaval u sebe a vracel jen nejakej identifikator (cislo, treba).

A taky to asi nema smysl delat u dotazu ktery nejdou natemplatovat (tj. je tam tech moznosti TOLIK, ze to proste nejde realne "predchroustat"), takze by se to pouzivalo jen na ty hodne bezny.

A ted mi nekdo prosimvas reknete, ze tohle jsou ty procedury co mu uz tu nekdo nabizel, ja mam pocit ze ano ale vim toho o databazich jen tolik co se Valentovi povedlo do mne na cviku nalejt. :-)

JANFROG: Hele, s kafem to jde celkem v pohode.