Обсуждение: Help with User-defined function in PostgreSQL with Visual C++
Hello I have problems defining user-defined types and functions in PostgreSQL using a Visual C++ development environment. In order to look for the solution I took the complex.c and complex.source files coming with the PostgreSQL distribution (src/tutorial). When I run the examples there is a server crash. I used both Visual C++ 2008 and 2005 for building the dll. I also used both PostgreSQL versions 8.4 and 9.0. All versions produce the same problem. Do you know how can I solve the problem ? Someone has a Visual C++ solution that works that can send me ? Many many thanks for your help ! I have been struggling around with this problem for several weeks without any success :-( Regards Esteban -- ------------------------------------------------------------ Prof. Esteban Zimanyi Department of Computer & Decision Engineering (CoDE) CP 165/15 Universite Libre de Bruxelles Avenue F. D. Roosevelt 50 B-1050 Brussels, Belgium fax: + 32.2.650.47.13 tel: + 32.2.650.31.85 e-mail: ezimanyi@ulb.ac.be Internet: http://code.ulb.ac.be/ ------------------------------------------------------------ -- ------------------------------------------------------------ Prof. Esteban Zimanyi Department of Computer & Decision Engineering (CoDE) CP 165/15 Universite Libre de Bruxelles Avenue F. D. Roosevelt 50 B-1050 Brussels, Belgium fax: + 32.2.650.47.13 tel: + 32.2.650.31.85 e-mail: ezimanyi@ulb.ac.be Internet: http://code.ulb.ac.be/ ------------------------------------------------------------
On Sun, Sep 26, 2010 at 12:56 AM, Esteban Zimanyi <estebanzimanyi@gmail.com> wrote: > When I run the examples there is a server crash. I used both Visual > C++ 2008 and 2005 for building the dll. I also used both PostgreSQL > versions 8.4 and 9.0. All versions produce the same problem. > > Do you know how can I solve the problem ? Someone has a Visual C++ > solution that works that can send me ? If you're developing your project as VC++ standalone project, codes in tutorials and contrib modules don't work at all, because they don't have __declspec(dllexport) for each function and variable to be exported. They will work well as long as you use mingw or special VC++ environment used to build the core. I had the same problems before, and I wrote some hacks for VC++. The codes in pg_reorg/lib in pgFoundry might be a help: http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/reorg/pg_reorg/lib/reorg.c http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/reorg/pg_reorg/lib/pgut/pgut-be.h -- Itagaki Takahiro
Re: Help with User-defined function in PostgreSQL with Visual C++
От
Euler Taveira de Oliveira
Дата:
Itagaki Takahiro escreveu: > I had the same problems before, and I wrote some hacks for VC++. > Isn't there such a code in core or am i missing something? Is it worth supporting the VC++ standalone projects? -- Euler Taveira de Oliveira http://www.timbira.com/
On Tue, Sep 28, 2010 at 5:13 AM, Euler Taveira de Oliveira <euler@timbira.com> wrote: > Itagaki Takahiro escreveu: >> I had the same problems before, and I wrote some hacks for VC++. >> > Isn't there such a code in core or am i missing something? Is it worth > supporting the VC++ standalone projects? Since we have PGDLLEXPORT in 9.0, we can mark some of exported functions with it in tutorial codes and maybe contrib modules. Is it worth doing? We don't need the marks in our build environment, but they might help users referencing our codes in standalone VC++ projects. -- Itagaki Takahiro
On Mon, Sep 27, 2010 at 8:45 PM, Itagaki Takahiro <itagaki.takahiro@gmail.com> wrote: > On Tue, Sep 28, 2010 at 5:13 AM, Euler Taveira de Oliveira > <euler@timbira.com> wrote: >> Itagaki Takahiro escreveu: >>> I had the same problems before, and I wrote some hacks for VC++. >>> >> Isn't there such a code in core or am i missing something? Is it worth >> supporting the VC++ standalone projects? > > Since we have PGDLLEXPORT in 9.0, we can mark some of exported > functions with it in tutorial codes and maybe contrib modules. > > Is it worth doing? We don't need the marks in our build environment, > but they might help users referencing our codes in standalone VC++ projects. If that (a) works and (b) reduces user confusion, +1 from me. We've gotten this question a few times lately. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
On Tue, Sep 28, 2010 at 9:51 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> Since we have PGDLLEXPORT in 9.0, we can mark some of exported >> functions with it in tutorial codes and maybe contrib modules. > > If that (a) works and (b) reduces user confusion, +1 from me. We've > gotten this question a few times lately. If we do so, many PGDLLEXPORT will be added: * 17 in src/tutorial * 507 in contrib for each exported PGFunction, _PG_init, and _PG_fini. Any objections? Am I missing something? -- Itagaki Takahiro
On Mon, Sep 27, 2010 at 11:09 PM, Itagaki Takahiro <itagaki.takahiro@gmail.com> wrote: > On Tue, Sep 28, 2010 at 9:51 AM, Robert Haas <robertmhaas@gmail.com> wrote: >>> Since we have PGDLLEXPORT in 9.0, we can mark some of exported >>> functions with it in tutorial codes and maybe contrib modules. >> >> If that (a) works and (b) reduces user confusion, +1 from me. We've >> gotten this question a few times lately. > > If we do so, many PGDLLEXPORT will be added: > * 17 in src/tutorial > * 507 in contrib > for each exported PGFunction, _PG_init, and _PG_fini. > > Any objections? Am I missing something? Oh - I didn't realize this meant marking lots of things in contrib that didn't otherwise need to be marked. Why do other people need this if we don't? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
On Tue, Sep 28, 2010 at 12:12 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> If we do so, many PGDLLEXPORT will be added: >> * 17 in src/tutorial >> * 507 in contrib >> for each exported PGFunction, _PG_init, and _PG_fini. > > Oh - I didn't realize this meant marking lots of things in contrib > that didn't otherwise need to be marked. Why do other people need > this if we don't? As I mentioned, we don't need the marks in our build environment at all. So, the PGDLLEXPORT marks are for users who refers our tutorials and contrib modules as sample codes. Personally, I learned many idioms from contrib modules, but didn't notice the tutorial directory. I think codes in contribs are often copied-and-pasted. So, if we add PGDLLEXPORTs to some places, I'd like to add them to contribs, too. -- Itagaki Takahiro
On Mon, Sep 27, 2010 at 11:26 PM, Itagaki Takahiro <itagaki.takahiro@gmail.com> wrote: > On Tue, Sep 28, 2010 at 12:12 PM, Robert Haas <robertmhaas@gmail.com> wrote: >>> If we do so, many PGDLLEXPORT will be added: >>> * 17 in src/tutorial >>> * 507 in contrib >>> for each exported PGFunction, _PG_init, and _PG_fini. >> >> Oh - I didn't realize this meant marking lots of things in contrib >> that didn't otherwise need to be marked. Why do other people need >> this if we don't? > > As I mentioned, we don't need the marks in our build environment at all. Why not? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
Itagaki Takahiro <itagaki.takahiro@gmail.com> writes: > On Tue, Sep 28, 2010 at 12:12 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> Oh - I didn't realize this meant marking lots of things in contrib >> that didn't otherwise need to be marked. Why do other people need >> this if we don't? > As I mentioned, we don't need the marks in our build environment at all. In that case, anybody who does need it should fix their build environment. I grow really weary of the idea that we should submit to arbitrary amounts of uglification of our source code so that it will deal with this week's Windows oddness. The Windows folk need to be willing to do a bit of work on their end. regards, tom lane
On Tue, Sep 28, 2010 at 3:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> As I mentioned, we don't need the marks in our build environment at all. > > In that case, anybody who does need it should fix their build > environment. > > I grow really weary of the idea that we should submit to arbitrary > amounts of uglification of our source code so that it will deal with > this week's Windows oddness. The Windows folk need to be willing to > do a bit of work on their end. Windows has 3 levels of function visibilities in a DLL: 1. exported from the DLL 2. module global, but not exported 3. static(private in file), of course not exported On UNIXes, 2 is always 1. So we don't have to distinguish between global and exported functions. But standard DLL projects on Windows require marking which functions should be exported. I'm not sure why we can build modules without any EXPORT marks, though we can do it actually... It is very unnatural on Windows. If we want to avoid adding PGDLLEXPORTs, we could have "sample MSVC project with proper settings" in tutorial or documentation instead. It should be opened with VC++ GUI (not from command line!) and can be generate DLLs in the same way we're using to build the core. -- Itagaki Takahiro
On 28/09/10 11:09, Itagaki Takahiro wrote: > On Tue, Sep 28, 2010 at 9:51 AM, Robert Haas <robertmhaas@gmail.com> wrote: >>> Since we have PGDLLEXPORT in 9.0, we can mark some of exported >>> functions with it in tutorial codes and maybe contrib modules. >> >> If that (a) works and (b) reduces user confusion, +1 from me. We've >> gotten this question a few times lately. > > If we do so, many PGDLLEXPORT will be added: > * 17 in src/tutorial > * 507 in contrib > for each exported PGFunction, _PG_init, and _PG_fini. > > Any objections? Am I missing something? For what it's worth, these macros are useful for more than Windows. They can be used with gcc's visibility features to reduce the size of the symbol table and therefore speed linking and backend startup. This isn't as important in a C-only program as it is in a C++ program (which has huge collections of private symbols) but it still won't hurt. If building with gcc4 on a non-Windows platform, the PGDLLEXPORT macro can be defined as: #define PGDLLEXPORT __attribute__ ((visibility("default"))) and gcc can be invoked with -fvisibility=hidden to make symbols not explicitly exported hidden by default. A handy advantage of this is that it'll cause code that would compile and run correctly on *nix and fail on Windows to also fail on *nix, making it easier for *nix based developers (ie sane, happy people) to catch issues that'll break Windows. Such macros also serve as documentation markers indicating public API. They're ugly, but they're not purely Windows ugly. -- Craig Ringer Tech-related writing: http://soapyfrogs.blogspot.com/
On Tue, Sep 28, 2010 at 09:26, Itagaki Takahiro <itagaki.takahiro@gmail.com> wrote: > On Tue, Sep 28, 2010 at 3:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> As I mentioned, we don't need the marks in our build environment at all. >> >> In that case, anybody who does need it should fix their build >> environment. >> >> I grow really weary of the idea that we should submit to arbitrary >> amounts of uglification of our source code so that it will deal with >> this week's Windows oddness. The Windows folk need to be willing to >> do a bit of work on their end. > > Windows has 3 levels of function visibilities in a DLL: > 1. exported from the DLL > 2. module global, but not exported > 3. static (private in file), of course not exported > > On UNIXes, 2 is always 1. So we don't have to distinguish between > global and exported functions. But standard DLL projects on Windows > require marking which functions should be exported. > > I'm not sure why we can build modules without any EXPORT marks, > though we can do it actually... It is very unnatural on Windows. > > > If we want to avoid adding PGDLLEXPORTs, we could have "sample MSVC > project with proper settings" in tutorial or documentation instead. > It should be opened with VC++ GUI (not from command line!) and can > be generate DLLs in the same way we're using to build the core. We're talking about the "export all symbols" thing, right? I *don't* think we want to recommend people to do that - it creates bloated DLL files, for no really good reason. Also, it's not just a matter of a msvc project - we do that with a perl hack (http://git.postgresql.org/gitweb?p=postgresql.git;a=blob;f=src/tools/msvc/gendef.pl;h=b8538dd79b8baf21ede87b2ec1aba0276fd3b3d9;hb=62b6aaa40b2abb26edf18d1cd00dffcac090f67a). It's not a good way. We might, however, want to add a specific section to the *documentation* about building extensions on Windows. We have section 35.9.6 which lists a bunch of OSes, where windows is clearly missing. But perhaps a complete section of it's own, like the one for pgxs in 35.9.6, would be even better? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Re: Help with User-defined function in PostgreSQL with Visual C++
От
Euler Taveira de Oliveira
Дата:
Magnus Hagander escreveu: > We might, however, want to add a specific section to the > *documentation* about building extensions on Windows. > +1. -- Euler Taveira de Oliveira http://www.timbira.com/
On Tue, Sep 28, 2010 at 6:16 PM, Magnus Hagander <magnus@hagander.net> wrote: > We're talking about the "export all symbols" thing, right? I *don't* > think we want to recommend people to do that - it creates bloated DLL > files, for no really good reason. Also, it's not just a matter of a > msvc project - we do that with a perl hack > (http://git.postgresql.org/gitweb?p=postgresql.git;a=blob;f=src/tools/msvc/gendef.pl;h=b8538dd79b8baf21ede87b2ec1aba0276fd3b3d9;hb=62b6aaa40b2abb26edf18d1cd00dffcac090f67a). > It's not a good way. What a great hacking! I agree that it is not recommendable, but users need to build their codes in different build environment from ours if so. > We might, however, want to add a specific section to the > *documentation* about building extensions on Windows +1. It will be a longer section than ones for other platforms. -- Itagaki Takahiro