From: | Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_upgrade code questions |
Date: | 2010-05-14 02:24:03 |
Message-ID: | 20100514112403.A443.52131E4D@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > >> ==== 2. extern PGDLLIMPORT ====
> > >> pg_upgrade has own definitions of
> > >> extern PGDLLIMPORT Oid binary_upgrade_next_xxx
> >
> > > The issue here is that you use PGDLLIMPORT where you are importing the
> > > variable, not where it is defined. For example, look at
> > > 'seq_page_cost'. You can see PGDLLIMPORT used where it is imported with
> > > 'extern', but not where is it defined.
> >
> > Right. Also we are intentionally not exposing those variables in any
> > backend .h file, because they are not meant for general use. So the
> > "extern PGDLLIMPORT" isn't going to be in the main backend and has to
> > be in pg_upgrade. This was discussed awhile ago when we put in those
> > variables, I believe.
>
> Yes, this was discussed.
I wonder some compilers or linkers might hide unexported global variables
from postgres.lib as if they are declared with 'static' specifiers.
I'm especially worried about Windows and MSVC. So, if Windows testers
can see it works, there was nothing to worry about.
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2010-05-14 02:48:49 | Re: wal_level and continuous archiving documentation |
Previous Message | Joseph Adams | 2010-05-14 01:47:37 | JSON manipulation functions |