Re: [HACKERS] PL/pgSQL - for discussion
От | dg@illustra.com (David Gould) |
---|---|
Тема | Re: [HACKERS] PL/pgSQL - for discussion |
Дата | |
Msg-id | 9803140741.AA05949@hawk.illustra.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] PL/pgSQL - for discussion (jwieck@debis.com (Jan Wieck)) |
Список | pgsql-hackers |
Jan and Vadim (I think) discuss: > > > > Why PL/pgSQL should be loadable PL? Why not built-in ? > > Would it be possible to add dirrect support for PL/pgSQL syntax > > to current parser ? ... > Well, PL/pgSQL could be compiled in and the pl_handler > function and language tuples set at bootstrap. But > incorporating the parser into the backends main parser isn't > nesseccary then either. Not that I think it's impossible, but > the current main parser is complex enough for me. I agree, for a language this simple, it would be nice to have it in the main parser. This might not be too hard since the existing statements are not really changing, only some new ones are added. eg: Select_Stmt := SELECT _name_list FROM _from_clause WHERE _where_clause_ ... + If_Stmt := IF _expression_ THEN _statement_list END + Loop_Stmt := ... Or whatever the grammar looks like. A bit harder is that the executor now has to sequence through the statements and handle branches and storing variables etc. > > > Someone gave a hint about global variables existing during a > > > session. What is a session than? One transaction? The > > > backends lifetime? And should global variables be visible by > > ^^^^^^^^^^^^^^^^^ > > This. Agree. > OK. > > > > more than one function? I vote for NO! In that case we need > > > something like packages of functions that share globals. > > > > Let's leave packages for future, but why session-level variables > > shouldn't be visible inside procedures right now? > > For security. At least I would like the visibility of global > variables depend on the functions owner. So users A and B can > use the same global name in their functions but the variables > are different. Not a problem. If the global variables are global only to the session they can be stored in allocated memory, not in the shared memory. Automatically then they are private to the user of that session and are destroyed when the session ends. > > > [<<label>>] > > > [DECLARE > > > -- declarations] > > > BEGIN > > > -- statements > > > END; > > > > Someday we'll have nested transactions... > > How about disallow using BEGIN/END as transaction control statements > > right now ? > > START/COMMIT/ROLLBACK/ABORT and nothing more... > > Right now! Hmmm, I like BEGIN TRAN/END TRAN/ABORT TRAN. I suppose there is a standard we should be following... Also, we probably should not start breaking existing applications, users get very fussy about that. > > > throw messages into the PostgreSQL elog mechanism. > > > > > > ELOG level 'format' [identifiers]; > > ^^^^^^^^^^ > > NO, pls - too postgres-ish! Just let ABORT to have 'format' etc and add > > PRINT (or something like this) to put some messages to application (via NOTICE). What is wrong with ELOG? It seems concise and does what is wanted, yes? Why add syntax? -dg David Gould dg@illustra.com 510.628.3783 or 510.305.9468 Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612 - I realize now that irony has no place in business communications.
В списке pgsql-hackers по дате отправления:
Предыдущее
От: dg@illustra.com (David Gould)Дата:
Сообщение: Re: [HACKERS] RVM -- recoverable virtual memory