Open 7.1 items

On Wed, 24 Jan 2001, Bruce Momjian wrote:

Here are my open 7.1 items. Thanks for shrinking the list so far.

---------------------------------------------------------------------------

FreeBSD locale bug

AFAIK, Tom have fixed it, if this bug is about -funsigned-char

Reorder INSERT firing in rules
Philip Warner UPDATE crash
JDBC LargeObject short read return value missing
SELECT cash_out(1) crashes all backends
LAZY VACUUM
FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"
Usernames limited in length
Does pg_dump preserve COMMENTs?
Failure of nested cursors in JDBC
JDBC setMaxRows() is global variable affecting other objects
Does JDBC Makefile need current dir?
Fix for pg_dump of bad system tables
Steve Howe failure query with rules
ODBC/JDBC not disconnecting properly?
Magnus Hagander ODBC issues?
Merge MySQL/PgSQL translation scripts
Fix ipcclean on Linux
Merge global and template BKI files?

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Here are my open 7.1 items. Thanks for shrinking the list so far.

SELECT cash_out(1) crashes all backends

This isn't a "must fix for 7.1", any more than it was for 7.0, 6.5,
or any other release back to the beginning of time. It's always been
possible to crash the backend by passing an incompatible argument to
a type input or output function. The type-checking system cannot
detect the error because these functions are (mostly) declared to
take "any" input type (zero entry in proargtypes[]).

The only clean way to fix this is to declare I/O functions honestly.
That will require (a) a type-system representation for "C string"
and (b) a solution to the circularity issue for user-defined types.
If the I/O functions have to be declared first, how can they refer
to the type?

Quite aside from the time involved, this will require an initdb.
It's a bit late in the cycle for that.

regards, tom lane

Bruce Momjian writes:

FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"

You're certainly not going to want to fix this now after having stared at
it for a year? It's not trivial.

Usernames limited in length

Yeah, they are. ;-)

If this is referring to pg_passwd, I just had a closer look and it's
really a desaster. Both password and username as well as line length and
file length (in lines) have arbitrary limits, sometimes not even
consistent ones. To fix this to a point where one is confident that
everything works one essentially would have to rewrite the whole thing.

Does pg_dump preserve COMMENTs?

Sure

Fix ipcclean on Linux

Consider it done.

Merge global and template BKI files?

Not this release.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Fix for pg_dump of bad system tables

Ok. I have made patches for fixing some of pg_dump problems(see
attached patches). The patches address the problem with user defined
functions, operators and aggregates. Could someone please review and
commit them if they look ok? (I'm now in US and have only very
expensive internet connection through an international phone call to
Japan in a hotel! Also I'm not quite sure "#arg" (stringification) is
portable enough in all platforms.) Or I could commit after going back
to Japan planned on Feb 2 if that's not too late.

However I have not address what Tom Lane said yet(actually I do not
understand what he says).

The other flavor of problems that pg_dump
has in this area are in doing inner joins across system catalogs ...

regards, tom lane

Index: common.c
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/bin/pg_dump/common.c,v
retrieving revision 1.49
diff -c -r1.49 common.c
*** common.c	2001/01/12 15:41:29	1.49
--- common.c	2001/01/21 01:38:48
***************
*** 86,95 ****
  		}
  	}

! /* should never get here */
! fprintf(stderr, "failed sanity check, type with oid %s was not found\n",
! oid);
! exit(2);
}

  /*
--- 86,93 ----
  		}
  	}

! /* no suitable type name was found */
! return(NULL);
}

/*
***************
*** 114,120 ****
/* should never get here */
fprintf(stderr, "failed sanity check, opr with oid %s was not found\n",
oid);
! exit(2);
}

--- 112,120 ----
  	/* should never get here */
  	fprintf(stderr, "failed sanity check, opr with oid %s was not found\n",
  			oid);
! 
! 	/* no suitable operator name was found */
! 	return(NULL);
  }

*** pg_dump.c.orig	Fri Jan 26 06:56:09 2001
--- pg_dump.c	Fri Jan 26 06:35:26 2001
***************
*** 2928,2933 ****
--- 2928,2942 ----
  			char	   *elemType;

  			elemType = findTypeByOid(tinfo, numTypes, tinfo[i].typelem, zeroAsOpaque);
+ 			if (elemType == NULL)
+ 			{
+ 				fprintf(stderr, "Notice: type for oid %s is not dumped.\n",
+ 						tinfo[i].typelem);
+ 				resetPQExpBuffer(q);
+ 				resetPQExpBuffer(delq);
+ 				continue;
+ 			}
+ 
  			appendPQExpBuffer(q, ", element = %s, delimiter = ", elemType);
  			formatStringLiteral(q, tinfo[i].typdelim);
  		}
***************
*** 3086,3091 ****
--- 3095,3101 ----
  	char		*listSep;
  	char		*listSepComma = ",";
  	char		*listSepNone = "";
+ 	char		*rettypename;

  	if (finfo[i].dumped)
  		return;
***************
*** 3147,3152 ****
--- 3157,3177 ----
  		char			*typname;

  		typname = findTypeByOid(tinfo, numTypes, finfo[i].argtypes[j], zeroAsOpaque);
+ 		if (typname == NULL)
+ 		{
+ 			fprintf(stderr, "Notice: function \"%s\" is not dumped.\n",
+ 					finfo[i].proname);
+ 
+ 			fprintf(stderr, "Reason: the %d th argument type name (oid %s) not found.\n",
+ 					j, finfo[i].argtypes[j]);
+ 			resetPQExpBuffer(q);
+ 			resetPQExpBuffer(fn);
+ 			resetPQExpBuffer(delqry);
+ 			resetPQExpBuffer(fnlist);
+ 			resetPQExpBuffer(asPart);
+ 			return;
+ 		}
+ 
  		appendPQExpBuffer(fn, "%s%s", 
  							(j > 0) ? "," : "", 
  							typname);
***************
*** 3159,3169 ****
  	resetPQExpBuffer(delqry);
  	appendPQExpBuffer(delqry, "DROP FUNCTION %s;\n", fn->data );

resetPQExpBuffer(q);
appendPQExpBuffer(q, "CREATE FUNCTION %s ", fn->data );
appendPQExpBuffer(q, "RETURNS %s%s %s LANGUAGE ",
(finfo[i].retset) ? "SETOF " : "",
! findTypeByOid(tinfo, numTypes, finfo[i].prorettype, zeroAsOpaque),
asPart->data);
formatStringLiteral(q, func_lang);

--- 3184,3211 ----
  	resetPQExpBuffer(delqry);
  	appendPQExpBuffer(delqry, "DROP FUNCTION %s;\n", fn->data );

+ 	rettypename = findTypeByOid(tinfo, numTypes, finfo[i].prorettype, zeroAsOpaque);
+ 
+ 	if (rettypename == NULL)
+ 	{
+ 		fprintf(stderr, "Notice: function \"%s\" is not dumped.\n",
+ 				finfo[i].proname);
+ 
+ 		fprintf(stderr, "Reason: return type name (oid %s) not found.\n",
+ 				finfo[i].prorettype);
+ 			resetPQExpBuffer(q);
+ 			resetPQExpBuffer(fn);
+ 			resetPQExpBuffer(delqry);
+ 			resetPQExpBuffer(fnlist);
+ 			resetPQExpBuffer(asPart);
+ 			return;
+ 	}
+ 
  	resetPQExpBuffer(q);
  	appendPQExpBuffer(q, "CREATE FUNCTION %s ", fn->data );
  	appendPQExpBuffer(q, "RETURNS %s%s %s LANGUAGE ",
  					  (finfo[i].retset) ? "SETOF " : "",
! 					  rettypename,
  					  asPart->data);
  	formatStringLiteral(q, func_lang);

***************
*** 3208,3213 ****
--- 3250,3261 ----
  dumpOprs(Archive *fout, OprInfo *oprinfo, int numOperators,
  		 TypeInfo *tinfo, int numTypes)
  {
+ #define OPR_NOTICE(arg) {\
+ 		fprintf(stderr, "Notice: operator \"%s\"(oid %s) is not dumped.\n",oprinfo[i].oprname, oprinfo[i].oid);\
+ 	fprintf(stderr, "Reason: " #arg);\
+ 	fprintf (stderr, " (oid %s) not found.\n",oprinfo[i].arg);\
+ 	}
+ 
  	int			i;
  	PQExpBuffer q = createPQExpBuffer();
  	PQExpBuffer delq = createPQExpBuffer();
***************
*** 3222,3227 ****
--- 3270,3276 ----

for (i = 0; i < numOperators; i++)
{
+ char *name;

resetPQExpBuffer(leftarg);
resetPQExpBuffer(rightarg);
***************
*** 3250,3271 ****
if (strcmp(oprinfo[i].oprkind, "r") == 0 ||
strcmp(oprinfo[i].oprkind, "b") == 0)
{
! appendPQExpBuffer(leftarg, ",\n\tLEFTARG = %s ",
! findTypeByOid(tinfo, numTypes, oprinfo[i].oprleft, zeroAsOpaque) );
}
if (strcmp(oprinfo[i].oprkind, "l") == 0 ||
strcmp(oprinfo[i].oprkind, "b") == 0)
{
! appendPQExpBuffer(rightarg, ",\n\tRIGHTARG = %s ",
! findTypeByOid(tinfo, numTypes, oprinfo[i].oprright, zeroAsOpaque) );
}
if (!(strcmp(oprinfo[i].oprcom, "0") == 0))
! appendPQExpBuffer(commutator, ",\n\tCOMMUTATOR = %s ",
! findOprByOid(oprinfo, numOperators, oprinfo[i].oprcom));

if (!(strcmp(oprinfo[i].oprnegate, "0") == 0))
! appendPQExpBuffer(negator, ",\n\tNEGATOR = %s ",
! findOprByOid(oprinfo, numOperators, oprinfo[i].oprnegate));

  		if (!(strcmp(oprinfo[i].oprrest, "-") == 0))
  			appendPQExpBuffer(restrictor, ",\n\tRESTRICT = %s ", oprinfo[i].oprrest);
--- 3299,3348 ----
  		if (strcmp(oprinfo[i].oprkind, "r") == 0 ||
  			strcmp(oprinfo[i].oprkind, "b") == 0)
  		{
! 		    name = findTypeByOid(tinfo, numTypes, 
! 								  oprinfo[i].oprleft, zeroAsOpaque);
! 			if (name == NULL)
! 			{
! 				OPR_NOTICE(oprleft);
! 				continue;
! 			}
! 			appendPQExpBuffer(leftarg, ",\n\tLEFTARG = %s ",name);
  		}
+ 
  		if (strcmp(oprinfo[i].oprkind, "l") == 0 ||
  			strcmp(oprinfo[i].oprkind, "b") == 0)
  		{
! 		    name = findTypeByOid(tinfo, numTypes, 
! 								  oprinfo[i].oprright, zeroAsOpaque);
! 			if (name == NULL)
! 			{
! 				OPR_NOTICE(oprright);
! 				continue;
! 			}
! 			appendPQExpBuffer(rightarg, ",\n\tRIGHTARG = %s ", name);
  		}
+ 
  		if (!(strcmp(oprinfo[i].oprcom, "0") == 0))
! 		{
! 			name = findOprByOid(oprinfo, numOperators, oprinfo[i].oprcom);
! 			if (name == NULL)
! 			{
! 				OPR_NOTICE(oprcom);
! 				continue;
! 			}
! 			appendPQExpBuffer(commutator, ",\n\tCOMMUTATOR = %s ", name);
! 		}

if (!(strcmp(oprinfo[i].oprnegate, "0") == 0))
! {
! name = findOprByOid(oprinfo, numOperators, oprinfo[i].oprnegate);
! if (name == NULL)
! {
! OPR_NOTICE(oprnegate);
! continue;
! }
! appendPQExpBuffer(negator, ",\n\tNEGATOR = %s ", name);
! }

if (!(strcmp(oprinfo[i].oprrest, "-") == 0))
appendPQExpBuffer(restrictor, ",\n\tRESTRICT = %s ", oprinfo[i].oprrest);
***************
*** 3274,3285 ****
appendPQExpBuffer(join, ",\n\tJOIN = %s ", oprinfo[i].oprjoin);

if (!(strcmp(oprinfo[i].oprlsortop, "0") == 0))
! appendPQExpBuffer(sort1, ",\n\tSORT1 = %s ",
! findOprByOid(oprinfo, numOperators, oprinfo[i].oprlsortop));

if (!(strcmp(oprinfo[i].oprrsortop, "0") == 0))
! appendPQExpBuffer(sort2, ",\n\tSORT2 = %s ",
! findOprByOid(oprinfo, numOperators, oprinfo[i].oprrsortop));

  		resetPQExpBuffer(delq);
  		appendPQExpBuffer(delq, "DROP OPERATOR %s (%s", oprinfo[i].oprname,
--- 3351,3376 ----
  			appendPQExpBuffer(join, ",\n\tJOIN = %s ", oprinfo[i].oprjoin);

if (!(strcmp(oprinfo[i].oprlsortop, "0") == 0))
! {
! name = findOprByOid(oprinfo, numOperators, oprinfo[i].oprlsortop);
! if (name == NULL)
! {
! OPR_NOTICE(oprlsortop);
! continue;
! }
! appendPQExpBuffer(sort1, ",\n\tSORT1 = %s ", name);
! }

if (!(strcmp(oprinfo[i].oprrsortop, "0") == 0))
! {
! name = findOprByOid(oprinfo, numOperators, oprinfo[i].oprrsortop);
! if (name == NULL)
! {
! OPR_NOTICE(oprrsortop);
! continue;
! }
! appendPQExpBuffer(sort2, ",\n\tSORT2 = %s ", name);
! }

  		resetPQExpBuffer(delq);
  		appendPQExpBuffer(delq, "DROP OPERATOR %s (%s", oprinfo[i].oprname,
***************
*** 3317,3322 ****
--- 3408,3419 ----
  dumpAggs(Archive *fout, AggInfo *agginfo, int numAggs,
  		 TypeInfo *tinfo, int numTypes)
  {
+ #define AGG_NOTICE(arg) {\
+ 		fprintf(stderr, "Notice: aggregate \"%s\"(oid %s) is not dumped.\n",agginfo[i].aggname, agginfo[i].oid);\
+ 	fprintf(stderr, "Reason: " #arg);\
+ 	fprintf (stderr, " (oid %s) not found.\n",agginfo[i].arg);\
+ 	}
+ 
  	int			i;
  	PQExpBuffer q = createPQExpBuffer();
  	PQExpBuffer delq = createPQExpBuffer();
***************
*** 3325,3344 ****

for (i = 0; i < numAggs; i++)
{
resetPQExpBuffer(details);

/* skip all the builtin oids */
if (atooid(agginfo[i].oid) <= g_last_builtin_oid)
continue;

! appendPQExpBuffer(details,
! "BASETYPE = %s, ",
! findTypeByOid(tinfo, numTypes, agginfo[i].aggbasetype, zeroAsAny + useBaseTypeName));

appendPQExpBuffer(details,
"SFUNC = %s, STYPE = %s",
! agginfo[i].aggtransfn,
! findTypeByOid(tinfo, numTypes, agginfo[i].aggtranstype, zeroAsOpaque + useBaseTypeName));

  		if (agginfo[i].agginitval)
  		{
--- 3422,3452 ----

for (i = 0; i < numAggs; i++)
{
+ char *name;
+
resetPQExpBuffer(details);

/* skip all the builtin oids */
if (atooid(agginfo[i].oid) <= g_last_builtin_oid)
continue;

! name = findTypeByOid(tinfo, numTypes, agginfo[i].aggbasetype, zeroAsAny + useBaseTypeName);
! if (name == NULL)
! {
! AGG_NOTICE(aggbasetype);
! continue;
! }
! appendPQExpBuffer(details, "BASETYPE = %s, ", name);

+ 		name = findTypeByOid(tinfo, numTypes, agginfo[i].aggtranstype, zeroAsOpaque + useBaseTypeName);
+ 		if (name == NULL)
+ 		{
+ 			AGG_NOTICE(aggtranstype);
+ 			continue;
+ 		}
  		appendPQExpBuffer(details,
  						  "SFUNC = %s, STYPE = %s",
! 						  agginfo[i].aggtransfn, name);

if (agginfo[i].agginitval)
{

Peter Eisentraut wrote:

Bruce Momjian writes:

FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"

You're certainly not going to want to fix this now after having stared at
it for a year? It's not trivial.

What does this item mean ?

Show quoted text

Usernames limited in length

Yeah, they are. ;-)

If this is referring to pg_passwd, I just had a closer look and it's
really a desaster. Both password and username as well as line length and
file length (in lines) have arbitrary limits, sometimes not even
consistent ones. To fix this to a point where one is confident that
everything works one essentially would have to rewrite the whole thing.

Does pg_dump preserve COMMENTs?

Sure

Fix ipcclean on Linux

Consider it done.

Merge global and template BKI files?

Not this release.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Sorry for my previous incomplete posting.

Peter Eisentraut wrote:

Bruce Momjian writes:

FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"

You're certainly not going to want to fix this now after having stared at
it for a year? It's not trivial.

What does this item mean ?
Is it the following ?

begin;
insert into pk (id) values (1);
update(delete from) pk where id=1;
ERROR: triggered data change violation on relation pk"

If so, isn't it a simple bug ?

Regards,
Hiroshi Inoue

Quoting Bruce Momjian <pgman@candle.pha.pa.us>:

Here are my open 7.1 items. Thanks for shrinking the list so far.

---------------------------------------------------------------------------

FreeBSD locale bug
Reorder INSERT firing in rules
Philip Warner UPDATE crash
JDBC LargeObject short read return value missing

Working on this on Saturday.

SELECT cash_out(1) crashes all backends
LAZY VACUUM
FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"
Usernames limited in length
Does pg_dump preserve COMMENTs?
Failure of nested cursors in JDBC

JDBC doesn't support cursors full stop yet.

JDBC setMaxRows() is global variable affecting other objects
Does JDBC Makefile need current dir?

No as it's obsolete in 7.1 ;-)

Fix for pg_dump of bad system tables
Steve Howe failure query with rules
ODBC/JDBC not disconnecting properly?

Client code not calling Connection.close() method.

Magnus Hagander ODBC issues?
Merge MySQL/PgSQL translation scripts
Fix ipcclean on Linux
Merge global and template BKI files?

Peter

--
Peter Mount peter@retep.org.uk
PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/
RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/

Hiroshi Inoue writes:

What does this item mean ?
Is it the following ?

begin;
insert into pk (id) values (1);
update(delete from) pk where id=1;
ERROR: triggered data change violation on relation pk"

If so, isn't it a simple bug ?

Depends on the definition of "bug". It's not spec compliant and it's not
documented and it's annoying. But it's been like this for a year and the
issue is well known and can normally be avoided. It looks like a
documentation to-do to me.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Bruce Momjian wrote:

Here are my open 7.1 items. Thanks for shrinking the list so far.

---------------------------------------------------------------------------

FreeBSD locale bug
Reorder INSERT firing in rules

I don't recall why this is wanted. AFAIK there's no reason
NOT to do so, except for the actual state of beeing far too
close to a release candidate.

Philip Warner UPDATE crash
JDBC LargeObject short read return value missing
SELECT cash_out(1) crashes all backends
LAZY VACUUM
FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"

A well known issue, and I've asked multiple times how exactly
we want to define the behaviour for deferred constraints. Do
foreign keys reference just to a key value and are happy with
it's existance, or do they refer to a particular row?

Consider you have a deferred "ON DELETE CASCADE" constraint
and do a DELETE, INSERT of a PK. Do the FK rows need to be
deleted or not?

Consider you have a deferred "ON DELETE RESTRICT" and "ON
UPDATE CASCADE" constraint. If you DELETE PK1 and UPDATE PK2
to PK1, the FK2 rows need to follow, but does PK2 inherit all
FK1 rows now so it's the master of both groups?

These are only two possible combinations. There are many to
think of. As said, I've asked before, but noone voted yet.
Move the item to 7.2 anyway, because changing this behaviour
would require massive changes in the trigger queue *and* the
generic RI triggers, which cannot be tested enough any more.

Jan

Usernames limited in length
Does pg_dump preserve COMMENTs?
Failure of nested cursors in JDBC
JDBC setMaxRows() is global variable affecting other objects
Does JDBC Makefile need current dir?
Fix for pg_dump of bad system tables
Steve Howe failure query with rules
ODBC/JDBC not disconnecting properly?
Magnus Hagander ODBC issues?
Merge MySQL/PgSQL translation scripts
Fix ipcclean on Linux
Merge global and template BKI files?

--
Bruce Momjian                        |  http://candle.pha.pa.us
pgman@candle.pha.pa.us               |  (610) 853-3000
+  If your life is a hard drive,     |  830 Blythe Avenue
+  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"

A well known issue, and I've asked multiple times how exactly
we want to define the behaviour for deferred constraints. Do
foreign keys reference just to a key value and are happy with
it's existance, or do they refer to a particular row?

Sorry, to answer late. I didn't know this needed clarification.
The answer is simple, foreign keys only reference a key value,
not a particular row.

Andreas

FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"

A well known issue, and I've asked multiple times how exactly
we want to define the behaviour for deferred constraints. Do
foreign keys reference just to a key value and are happy with
it's existance, or do they refer to a particular row?

I think first. The last is closer to OODBMS world, not to [O]RDBMS one.

Consider you have a deferred "ON DELETE CASCADE" constraint
and do a DELETE, INSERT of a PK. Do the FK rows need to be
deleted or not?

Good example. I think FK should not be deleted. If someone really
want to delete "old" FK then he can do

DELETE PK;
SET CONSTRAINT ... IMMEDIATE; -- FK need to be deleted here
INSERT PK;

Consider you have a deferred "ON DELETE RESTRICT" and "ON
UPDATE CASCADE" constraint. If you DELETE PK1 and UPDATE PK2
to PK1, the FK2 rows need to follow, but does PK2 inherit all
FK1 rows now so it's the master of both groups?

Yes. Again one can use SET CONSTRAINT to achieve desirable results.
It seems that SET CONSTRAINT was designed for these purposes - ie
for better flexibility.

Though, it would be better to look how other DBes handle all these
cases -:)

Vadim

Jan Wieck <janwieck@Yahoo.com> writes:

Bruce Momjian wrote:

Reorder INSERT firing in rules

I don't recall why this is wanted. AFAIK there's no reason
NOT to do so, except for the actual state of beeing far too
close to a release candidate.

I think I've been the main person arguing for this change, but I
agree with Jan that this late in the cycle is not the time to be
making such decisions. Let's discuss it again during 7.2 cycle.

regards, tom lane

[ Charset ISO-8859-1 unsupported, converting... ]

Quoting Bruce Momjian <pgman@candle.pha.pa.us>:

Here are my open 7.1 items. Thanks for shrinking the list so far.

---------------------------------------------------------------------------

FreeBSD locale bug
Reorder INSERT firing in rules
Philip Warner UPDATE crash
JDBC LargeObject short read return value missing

Working on this on Saturday.

OK.

SELECT cash_out(1) crashes all backends
LAZY VACUUM
FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"
Usernames limited in length
Does pg_dump preserve COMMENTs?
Failure of nested cursors in JDBC

JDBC doesn't support cursors full stop yet.

Removed from list. Doesn't even seem worth adding to TODO.

JDBC setMaxRows() is global variable affecting other objects
Does JDBC Makefile need current dir?

No as it's obsolete in 7.1 ;-)

Removed.

Fix for pg_dump of bad system tables
Steve Howe failure query with rules
ODBC/JDBC not disconnecting properly?

Client code not calling Connection.close() method.

Removed. ODBC seems to have a problem, though.

Thanks.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Here are my open 7.1 items. Thanks for shrinking the list so far.

SELECT cash_out(1) crashes all backends

OK, removed from 'open' list and added to TODO. Actually, I can't get
the crash to happen except with cash_out. Is there another *out
function you can get to fail.

This isn't a "must fix for 7.1", any more than it was for 7.0, 6.5,
or any other release back to the beginning of time. It's always been
possible to crash the backend by passing an incompatible argument to
a type input or output function. The type-checking system cannot
detect the error because these functions are (mostly) declared to
take "any" input type (zero entry in proargtypes[]).

The only clean way to fix this is to declare I/O functions honestly.
That will require (a) a type-system representation for "C string"
and (b) a solution to the circularity issue for user-defined types.
If the I/O functions have to be declared first, how can they refer
to the type?

Quite aside from the time involved, this will require an initdb.
It's a bit late in the cycle for that.

regards, tom lane

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

SELECT cash_out(1) crashes all backends

OK, removed from 'open' list and added to TODO. Actually, I can't get
the crash to happen except with cash_out. Is there another *out
function you can get to fail.

Any pass-by-reference type; also most if not all input functions.

regards, tom lane

Bruce Momjian writes:

FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"

You're certainly not going to want to fix this now after having stared at
it for a year? It's not trivial.

Moved to TODO.

Usernames limited in length

Yeah, they are. ;-)

If this is referring to pg_passwd, I just had a closer look and it's
really a desaster. Both password and username as well as line length and
file length (in lines) have arbitrary limits, sometimes not even
consistent ones. To fix this to a point where one is confident that
everything works one essentially would have to rewrite the whole thing.

Added to TODO:

* Fix username/password length limits in all areas

Does pg_dump preserve COMMENTs?

Sure

OK, thanks. Someone submitted a patch, and I wasn't sure how to handle
it. I thought it did it already.

Fix ipcclean on Linux

Consider it done.

Thanks.

Merge global and template BKI files?

Not this release.

Added to TODO.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:

FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"

A well known issue, and I've asked multiple times how exactly
we want to define the behaviour for deferred constraints. Do
foreign keys reference just to a key value and are happy with
it's existance, or do they refer to a particular row?

Sorry, to answer late. I didn't know this needed clarification.
The answer is simple, foreign keys only reference a key value,
not a particular row.

Cite chapter and verse in the spec, please?

regards, tom lane

I was woundering if any of you have seen this problem.

I have been running a system using a postgres 6.5 database. After a while
I realized the system wasn't very active so I looked into it. I tryed to view
all the tables in the database using the \d command, but it return:

- Couldn't find any tables, sequences or indices!

So I then tried to do a select statement from the table, which worked,
although no data was returned, but the table structure was correct.

I have backed up my database and have been trying to recover my data with no
luck. I am able to vacuum the tables and have it tell me that there are
several those tuples in each table, yet I still cant view the data.

Any suggestions?

Thanks,

Stefan Klopp

ecmarket

At 07:24 26/01/01 +0900, Tatsuo Ishii wrote:

Fix for pg_dump of bad system tables

Ok. I have made patches for fixing some of pg_dump problems(see
attached patches).

...

Also I'm not quite sure "#arg" (stringification) is
portable enough in all platforms.)

The patch looks fine to me, but I have no idea how portable #arg is - does
anybody else have some facts on the matter:

+#define AGG_NOTICE(arg) {\
+               fprintf(stderr, "Notice: aggregate \"%s\"(oid %s) is not
dumped.\n",agginfo[i].aggname, a
+       fprintf(stderr, "Reason: " #arg);\
+       fprintf (stderr, " (oid %s) not found.\n",agginfo[i].arg);\
+       }
+

It's easy enough to change the macros to take 2 params, and that would be
my inclination if it's not a solid part of the C standard (for any
non-trivial definintion of 'solid').

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

Philip Warner <pjw@rhyme.com.au> writes:

Also I'm not quite sure "#arg" (stringification) is
portable enough in all platforms.)

The patch looks fine to me, but I have no idea how portable #arg is

Use the CppAsString macro from our c.h ... that's what it's for.

It's actually fairly unlikely that anyone still uses a compiler that
doesn't grok #arg and yet can handle the other ANSI-isms that Postgres
requires. However, we may as well stick to the coding conventions
we have...

regards, tom lane

At 07:24 26/01/01 +0900, Tatsuo Ishii wrote:

Fix for pg_dump of bad system tables

Ok. I have made patches for fixing some of pg_dump problems(see
attached patches). The patches address the problem with user defined
functions, operators and aggregates.

These have now been applied with minor modifications.

However I have not address what Tom Lane said yet(actually I do not
understand what he says).

The other flavor of problems that pg_dump
has in this area are in doing inner joins across system catalogs ...

This refers to things like:

SELECT c.relname
FROM pg_index i, pg_class c
WHERE i.indrelid = %s
AND i.indisprimary
AND c.oid = i.indexrelid

ie. where two or more relations are crossed (pg_index and pg_class in this
case). It assumes that the metadata is valid, and will not highlight
missing data in the secondary table. We should be doing outer joins:

SELECT c.relname
FROM pg_index i LEFT OUTER JOIN pg_class c on c.oid = i.indexrelid
WHERE i.indrelid = %s
AND i.indisprimary

and checking for nulls using PQgetisnull. I have actually done this for a
couple of SELECTs (including the above one), and marked all the others as
'XXXX: use LOJ'. There are only 2 or 3 more, but they require a little more
thought (an inderstanding) before I change them.

In my view this should be considered a 'work-in-progress' and not hold up
7.1 since the problem has been there for a long time.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

I assume this addresses the open item:

Fix for pg_dump of bad system tables

I will remove it from the list. Thanks.

At 07:24 26/01/01 +0900, Tatsuo Ishii wrote:

Fix for pg_dump of bad system tables

Ok. I have made patches for fixing some of pg_dump problems(see
attached patches). The patches address the problem with user defined
functions, operators and aggregates.

These have now been applied with minor modifications.

However I have not address what Tom Lane said yet(actually I do not
understand what he says).

The other flavor of problems that pg_dump
has in this area are in doing inner joins across system catalogs ...

This refers to things like:

SELECT c.relname
FROM pg_index i, pg_class c
WHERE i.indrelid = %s
AND i.indisprimary
AND c.oid = i.indexrelid

ie. where two or more relations are crossed (pg_index and pg_class in this
case). It assumes that the metadata is valid, and will not highlight
missing data in the secondary table. We should be doing outer joins:

SELECT c.relname
FROM pg_index i LEFT OUTER JOIN pg_class c on c.oid = i.indexrelid
WHERE i.indrelid = %s
AND i.indisprimary

and checking for nulls using PQgetisnull. I have actually done this for a
couple of SELECTs (including the above one), and marked all the others as
'XXXX: use LOJ'. There are only 2 or 3 more, but they require a little more
thought (an inderstanding) before I change them.

In my view this should be considered a 'work-in-progress' and not hold up
7.1 since the problem has been there for a long time.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

At 23:14 27/01/01 -0500, Bruce Momjian wrote:

I assume this addresses the open item:

Fix for pg_dump of bad system tables

I will remove it from the list. Thanks.

I'd remove it from the 'Required for 7.1' list, but leave it on the TODO
list, since the task is not quite complete.

At 07:24 26/01/01 +0900, Tatsuo Ishii wrote:

Fix for pg_dump of bad system tables

Ok. I have made patches for fixing some of pg_dump problems(see
attached patches). The patches address the problem with user defined
functions, operators and aggregates.

These have now been applied with minor modifications.

...

In my view this should be considered a 'work-in-progress' and not hold up
7.1 since the problem has been there for a long time.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

At 23:14 27/01/01 -0500, Bruce Momjian wrote:

I assume this addresses the open item:

Fix for pg_dump of bad system tables

I will remove it from the list. Thanks.

I'd remove it from the 'Required for 7.1' list, but leave it on the TODO
list, since the task is not quite complete.

OK, do you have some text for me.

FYI, the "open" list are not all must-do items for 7.1. They are merely
items that either need to be done, or moved to the TODO list. It is up
to the group to decide which one they want.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Ok. I have made patches for fixing some of pg_dump problems(see
attached patches). The patches address the problem with user defined
functions, operators and aggregates.

These have now been applied with minor modifications.

Thanks. BTW, are you going to make a back patch for the 7.0.x tree?
I'm sure we are going to have lots of complaints from users who are
developing their own user defined functions and about to use pg_dump
to upgrade to 7.1 after it is officially released...
--
Tatsuo Ishii

Also I'm not quite sure "#arg" (stringification) is
portable enough in all platforms.)

The patch looks fine to me, but I have no idea how portable #arg is

Use the CppAsString macro from our c.h ... that's what it's for.

It's actually fairly unlikely that anyone still uses a compiler that
doesn't grok #arg and yet can handle the other ANSI-isms that Postgres
requires. However, we may as well stick to the coding conventions
we have...

Oh I see.
--
Tatsuo Ishii

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

Thanks. BTW, are you going to make a back patch for the 7.0.x tree?
I'm sure we are going to have lots of complaints from users who are
developing their own user defined functions and about to use pg_dump
to upgrade to 7.1 after it is officially released...

No more than in any prior release, AFAICS; these issues have been there
for a long time. I doubt that a back-patch is warranted.

regards, tom lane

At 02:17 30/01/01 +0900, Tatsuo Ishii wrote:

Ok. I have made patches for fixing some of pg_dump problems(see
attached patches). The patches address the problem with user defined
functions, operators and aggregates.

These have now been applied with minor modifications.

Thanks. BTW, are you going to make a back patch for the 7.0.x tree?
I'm sure we are going to have lots of complaints from users who are
developing their own user defined functions and about to use pg_dump
to upgrade to 7.1 after it is officially released...

Sorry for the delay, but this set of patches were targetted at trapping bad
metadata and as such are probably not appropriate for backporting. However,
some months ago, Tom did modify pg_dump for the new function manager
interface. It might be worth making a backpatch for this available.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/