Re: pg_proc.probin should become text?
От | Pavel Stehule |
---|---|
Тема | Re: pg_proc.probin should become text? |
Дата | |
Msg-id | 162867790908040758m42bdbbs4b23b4a54731c18b@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_proc.probin should become text? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
2009/8/4 Tom Lane <tgl@sss.pgh.pa.us>: > Pavel Stehule <pavel.stehule@gmail.com> writes: >> I agree, so information about patch would be store in text field. But >> I am not sure, if your fix isn't too simply. I haven't plan to compile >> plpgsql to C or to binary code. But could be interesting link postgres >> with some virtual machine like parrot or lua vm, and translate plpgsql >> to p code. It's maybe far future. > >> Early future is integration main SQL parser to plpgsql. I am not sure, >> but maybe we will need some persistent cache for store parametrized >> sql queries. I though about store it in probin column. > > Well, probin is the wrong place for any such thing anyhow. Regardless > of datatype issues, the system is clearly built on the assumption that > the value of probin is to be specified *by the user* in CREATE FUNCTION. > If you want a cache for derived information it would need to be a new > column. > > (I remain of the opinion that caching such stuff in pg_proc would be > a bad design decision. Every data structure that goes to disk is > another data structure that you cannot easily change. There just isn't > enough gain there to justify the maintenance headaches.) ook, I agree - but I am not sure, so some cache will be necessary. Pavel > > regards, tom lane >
В списке pgsql-hackers по дате отправления: