Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
On Thu, May 13, 2010 at 5:06 PM, Bruce Momjian br...@momjian.us 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
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 in
On Fri, May 14, 2010 at 5:34 AM, Bruce Momjian br...@momjian.us wrote:
Takahiro Itagaki wrote:
Bruce Momjian br...@momjian.us wrote:
2. extern PGDLLIMPORT
pg_upgrade has own definitions of
extern PGDLLIMPORT Oid binary_upgrade_next_xxx
The issue here is that you
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
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
On Thu, May 13, 2010 at 8:22 AM, Devrim GÜNDÜZ dev...@gunduz.org 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
Magnus Hagander wrote:
On Thu, May 13, 2010 at 8:22 AM, Devrim G?ND?Z dev...@gunduz.org 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
On Thu, May 13, 2010 at 5:06 PM, Bruce Momjian br...@momjian.us wrote:
Magnus Hagander wrote:
On Thu, May 13, 2010 at 8:22 AM, Devrim G?ND?Z dev...@gunduz.org wrote:
On Thu, 2010-05-13 at 15:13 +0900, Takahiro Itagaki wrote:
4. EDB_NATIVE_LANG
Of course it is commented out with
Magnus Hagander mag...@hagander.net writes:
On Thu, May 13, 2010 at 5:06 PM, Bruce Momjian br...@momjian.us 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
Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
On Thu, May 13, 2010 at 5:06 PM, Bruce Momjian br...@momjian.us 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
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 in
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
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 would
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 the
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 following
Bruce Momjian br...@momjian.us 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
Bruce Momjian br...@momjian.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
Takahiro Itagaki wrote:
Bruce Momjian br...@momjian.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
19 matches
Mail list logo
