Re: 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(at)ulb(dot)ac(dot)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(at)ulb(dot)ac(dot)be
Internet: http://code.ulb.ac.be/
------------------------------------------------------------

On Sun, Sep 26, 2010 at 12:56 AM, Esteban Zimanyi
<estebanzimanyi(at)gmail(dot)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

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(at)timbira(dot)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(dot)takahiro(at)gmail(dot)com> wrote:
> On Tue, Sep 28, 2010 at 5:13 AM, Euler Taveira de Oliveira
> <euler(at)timbira(dot)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(at)gmail(dot)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(dot)takahiro(at)gmail(dot)com> wrote:
> On Tue, Sep 28, 2010 at 9:51 AM, Robert Haas <robertmhaas(at)gmail(dot)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(at)gmail(dot)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(dot)takahiro(at)gmail(dot)com> wrote:
> On Tue, Sep 28, 2010 at 12:12 PM, Robert Haas <robertmhaas(at)gmail(dot)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(dot)takahiro(at)gmail(dot)com> writes:
> On Tue, Sep 28, 2010 at 12:12 PM, Robert Haas <robertmhaas(at)gmail(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)gmail(dot)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(dot)takahiro(at)gmail(dot)com> wrote:
> On Tue, Sep 28, 2010 at 3:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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/

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(at)hagander(dot)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