Re: [HACKERS] SIGSEGV on CREATE FUNCTION with plpgsql
От | wieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [HACKERS] SIGSEGV on CREATE FUNCTION with plpgsql |
Дата | |
Msg-id | m118gfv-0003kvC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] SIGSEGV on CREATE FUNCTION with plpgsql (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> > Wayne Piekarski <wayne@senet.com.au> writes: > > So can someone give me some advice? Do you want me to provide a stack dump > > or something? > > A stack trace might help --- I'm not sure why you are seeing this > problem if there are no functions approaching 4k of text. Would be interesting if the problem is index related. I still wonder (while looking at the code) what that ProcedureSrcIndex is really good for. I've tracked it down that it is only once used in pg_proc.c to check if an sql language function that implements a SET already exists (weired method to do IMHO). The code was already there in version 1.1 (initial load) of the code, so it might be an old Postgres 4.2 thing that's obsolete. Additionally, very doubtful, is the fact that we considered functions returning SET's as broken, so again I wonder if there's any code that automatically creates such functions (if not created automatically like the _RET rules of views are, identifying by this wouldn't allways work). The targetlists attached to SET functions don't work, so I assume removing the index wouldn't break anything. I'll dig out the 4.2 sources and search for a reason for that index there. If I find anything, I can check if that's still in our code. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #========================================= wieck@debis.com (Jan Wieck) #
В списке pgsql-hackers по дате отправления: