Tom Lane wrote:
> Magnus Hagander writes:
>> On Thu, May 13, 2010 at 5:06 PM, Bruce Momjian wrote:
>>> I have added SGML comments to comment out the text that mentions EDB
>>> Advanced Server. Is that enough? Should I remove the text from the
>>> SGML? Should I move it to the bottom of the SGM
On Fri, May 14, 2010 at 5:34 AM, Bruce Momjian wrote:
> Takahiro Itagaki wrote:
>>
>> Bruce Momjian wrote:
>>
>> > > >> 2. extern PGDLLIMPORT
>> > > >> pg_upgrade has own definitions of
>> > > >> extern PGDLLIMPORT Oid binary_upgrade_next_xxx
>> > >
>> > > > The issue here is that you u
On Thu, 2010-05-13 at 17:19 +0200, Magnus Hagander wrote:
> I say remove it. On all accounts.
>
> There's a fork of postgres for EDB AS, shouldn't there be a fork of
> pg_upgrade the same way, if it requires special code? The code in
> community postgresql certainly shouldn't have any EDB AS code
Takahiro Itagaki wrote:
>
> Bruce Momjian 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, n
Bruce Momjian 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
Tom Lane wrote:
> Bruce Momjian writes:
> > Takahiro Itagaki wrote:
> >> 2. extern PGDLLIMPORT
> >> pg_upgrade has own definitions of
> >> extern PGDLLIMPORT Oid binary_upgrade_next_xxx
> >> in pg_upgrade_sysoids.c. But those variables are not declared as
> >> PGDLLIMPORT in the core. Ca
Bruce Momjian writes:
> Takahiro Itagaki wrote:
>> 2. extern PGDLLIMPORT
>> pg_upgrade has own definitions of
>> extern PGDLLIMPORT Oid binary_upgrade_next_xxx
>> in pg_upgrade_sysoids.c. But those variables are not declared as
>> PGDLLIMPORT in the core. Can we access unexported variabl
Takahiro Itagaki wrote:
> I read pg_upgrade code glance over, and found 4 issues in it.
> Are there any issues to be fixed before 9.0 release?
>
> 1. NAMEDATASIZE
> 2. extern PGDLLIMPORT
> 3. pathSeparator
> 4. EDB_NATIVE_LANG
>
> 1. NAMEDATASIZE
> pg_upgrade has the fol
Josh Berkus wrote:
> On 5/13/10 10:14 AM, Bruce Momjian wrote:
> > I am trying to think of this as a non-EnterpriseDB employee. If suppose
> > Greenplum had given us a utility and they wanted it to work with their
> > version of the database, what accommodation would we make for them? I
> > agree
On 5/13/10 10:14 AM, Bruce Momjian wrote:
> I am trying to think of this as a non-EnterpriseDB employee. If suppose
> Greenplum had given us a utility and they wanted it to work with their
> version of the database, what accommodation would we make for them? I
> agree on the documentation, but wo
Bruce Momjian wrote:
Indeed. Given the (presumably large) delta between EDB's code and ours,
having to have some delta in pg_upgrade isn't going to make much
difference for them. I think the community code and docs should
completely omit any mention of that.
I am trying to think of thi
On Thu, 2010-05-13 at 17:19 +0200, Magnus Hagander wrote:
> I say remove it. On all accounts.
>
> There's a fork of postgres for EDB AS, shouldn't there be a fork of
> pg_upgrade the same way, if it requires special code? The code in
> community postgresql certainly shouldn't have any EDB AS code
Tom Lane wrote:
> Magnus Hagander writes:
> > On Thu, May 13, 2010 at 5:06 PM, Bruce Momjian wrote:
> >> I have added SGML comments to comment out the text that mentions EDB
> >> Advanced Server. ?Is that enough? ?Should I remove the text from the
> >> SGML? ?Should I move it to the bottom of the
Magnus Hagander writes:
> On Thu, May 13, 2010 at 5:06 PM, Bruce Momjian wrote:
>> I have added SGML comments to comment out the text that mentions EDB
>> Advanced Server. Is that enough? Should I remove the text from the
>> SGML? Should I move it to the bottom of the SGML? Should I remove th
On Thu, May 13, 2010 at 5:06 PM, Bruce Momjian wrote:
> Magnus Hagander wrote:
>> On Thu, May 13, 2010 at 8:22 AM, Devrim G?ND?Z wrote:
>> > On Thu, 2010-05-13 at 15:13 +0900, Takahiro Itagaki wrote:
>> >> 4. EDB_NATIVE_LANG
>> >> Of course it is commented out with #ifdef, but do we hav
Magnus Hagander wrote:
> On Thu, May 13, 2010 at 8:22 AM, Devrim G?ND?Z wrote:
> > On Thu, 2010-05-13 at 15:13 +0900, Takahiro Itagaki wrote:
> >> 4. EDB_NATIVE_LANG
> >> Of course it is commented out with #ifdef, but do we have codes
> >> for EDB in core?
> >
> > I was about to raise si
On Thu, May 13, 2010 at 8:22 AM, Devrim GÜNDÜZ wrote:
> On Thu, 2010-05-13 at 15:13 +0900, Takahiro Itagaki wrote:
>> 4. EDB_NATIVE_LANG
>> Of course it is commented out with #ifdef, but do we have codes
>> for EDB in core?
>
> I was about to raise similar thing, for the documentation:
>
On Thu, 2010-05-13 at 15:13 +0900, Takahiro Itagaki wrote:
> 4. EDB_NATIVE_LANG
> Of course it is commented out with #ifdef, but do we have codes
> for EDB in core?
I was about to raise similar thing, for the documentation:
http://developer.postgresql.org/pgdocs/postgres/pgupgrade.html
I read pg_upgrade code glance over, and found 4 issues in it.
Are there any issues to be fixed before 9.0 release?
1. NAMEDATASIZE
2. extern PGDLLIMPORT
3. pathSeparator
4. EDB_NATIVE_LANG
1. NAMEDATASIZE
pg_upgrade has the following definition, but should it be just NAM
19 matches
Mail list logo
