Re: [GENERAL] Re: "don't know how to print type 715"
От | Jose' Soares |
---|---|
Тема | Re: [GENERAL] Re: "don't know how to print type 715" |
Дата | |
Msg-id | 36066B96.31CAEF41@sferacarta.com обсуждение исходный текст |
Ответ на | Re: "don't know how to print type 715" ("Carilda A. Thomas" <agacat@earthlink.net>) |
Список | pgsql-general |
Carilda A. Thomas wrote: > > Since I have now seen two other people complain about this, I will join > the fray. > > I am running Solaris 2.6, Postgresql v6.3.2. > I have also gotten the same notice on FreeBSD 2.1.<something, I forget, > but not the threaded one -- this was for a client a while back) running > v6.3.1 > > Well, the "bug" only happens if one forces the complete build to use > dynamic libraries (.so instead of .a). > > And, no, I do NOT accept the Microsoft-type solution: "don't use > dynamic libraries." > > It doesn't seem to have any effect on operation other than being > annoying.... > Other info: The freeBSD was built with gcc 2.7.<something>; the Solaris > 2.6 was built with gcc 2.8.1. All the auxiliary programs (readline, > history, etc.) are the latest versions (I'm too lazy to look right now) > and linked in as dynamic, also. > > A bogus value is being passed somewhere, and the function it winds up in > just doesn't know what to do with it. I didn't have the time to chase > down the path it was using to get there because I am not that familiar > with the internals. > > This message appears to show up in anything related to a trigger -- > whether it's a restriction in the schema definition or a manually > created trigger. > > cat The problem should be connected with DEBUG, I solved my problem getting off the -d parameter from postmaster command line. Another way to have this message should be compiling the parser subdirectory with -DPARSEDEBUG. (See the reply of Thomas G. Lockhart). Jose'
В списке pgsql-general по дате отправления: