Re: [PATCHES] TODO item - tid operator
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Mark Kirkwood wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
Uh, why do we need this at all? NOT (tid = tid) covers the
functionality already.
tid should be a fully functional type, at least for = and !=.
I disagree strongly with renumbering existing hand-assigned OIDs for
this. There's too much risk of breakage and no benefit.
Agreed.
Also, you forgot to add the negator cross-links between the operators.
OK.
New patch, with no OID renumbering, plus the negators are there now :-)
Thanks for the critique guys!
regards
Mark
Index: src/backend/utils/adt/tid.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/tid.c,v
retrieving revision 1.49
diff -c -r1.49 tid.c
*** src/backend/utils/adt/tid.c 27 May 2005 00:57:49 - 1.49
--- src/backend/utils/adt/tid.c 26 Oct 2005 05:07:36 -
***
*** 174,180
arg1-ip_posid == arg2-ip_posid);
}
- #ifdef NOT_USED
Datum
tidne(PG_FUNCTION_ARGS)
{
--- 174,179
***
*** 185,191
BlockIdGetBlockNumber((arg2-ip_blkid)) ||
arg1-ip_posid != arg2-ip_posid);
}
- #endif
/*
* Functions to get latest tid of a specified tuple.
--- 184,189
Index: src/include/utils/builtins.h
===
RCS file: /projects/cvsroot/pgsql/src/include/utils/builtins.h,v
retrieving revision 1.267
diff -c -r1.267 builtins.h
*** src/include/utils/builtins.h 18 Oct 2005 20:38:58 - 1.267
--- src/include/utils/builtins.h 26 Oct 2005 05:07:37 -
***
*** 530,535
--- 530,536
extern Datum tidrecv(PG_FUNCTION_ARGS);
extern Datum tidsend(PG_FUNCTION_ARGS);
extern Datum tideq(PG_FUNCTION_ARGS);
+ extern Datum tidne(PG_FUNCTION_ARGS);
extern Datum currtid_byreloid(PG_FUNCTION_ARGS);
extern Datum currtid_byrelname(PG_FUNCTION_ARGS);
Index: src/include/catalog/pg_proc.h
===
RCS file: /projects/cvsroot/pgsql/src/include/catalog/pg_proc.h,v
retrieving revision 1.387
diff -c -r1.387 pg_proc.h
*** src/include/catalog/pg_proc.h 15 Oct 2005 02:49:42 - 1.387
--- src/include/catalog/pg_proc.h 26 Oct 2005 05:07:40 -
***
*** 1625,1630
--- 1625,1632
DATA(insert OID = 1291 ( array_length_coerce PGNSP PGUID 12 f f t f
s 3 2277 2277 23 16 _null_ _null_ _null_ array_length_coerce - _null_ ));
DESCR(adjust any array to new element typmod);
+ DATA(insert OID = 2601 ( tidne PGNSP PGUID 12 f f t
f i 2 16 27 27 _null_ _null_ _null_ tidne - _null_ ));
+ DESCR(not equal);
DATA(insert OID = 1292 ( tideq PGNSP PGUID 12 f f t
f i 2 16 27 27 _null_ _null_ _null_ tideq - _null_ ));
DESCR(equal);
DATA(insert OID = 1293 ( currtid PGNSP PGUID 12 f f t f v 2
27 26 27 _null_ _null_ _null_ currtid_byreloid - _null_ ));
Index: src/include/catalog/pg_operator.h
===
RCS file: /projects/cvsroot/pgsql/src/include/catalog/pg_operator.h,v
retrieving revision 1.137
diff -c -r1.137 pg_operator.h
*** src/include/catalog/pg_operator.h 15 Oct 2005 02:49:42 - 1.137
--- src/include/catalog/pg_operator.h 26 Oct 2005 05:07:41 -
***
*** 128,135
DATA(insert OID = 389 ( !! PGNSP PGUID l f 0 20
1700 0 0 0 0 0 0 numeric_fac - - ));
DATA(insert OID = 385 ( = PGNSP PGUID b t 29 29
16 385 0 0 0 0 0 cideq eqsel eqjoinsel ));
DATA(insert OID = 386 ( = PGNSP PGUID b t 22 22
16 386 0 0 0 0 0 int2vectoreq eqsel eqjoinsel ));
! DATA(insert OID = 387 ( = PGNSP PGUID b f 27 27
16 387 0 0 0 0 0 tideq eqsel eqjoinsel ));
#define TIDEqualOperator 387
DATA(insert OID = 410 ( =PGNSP PGUID b t 20 20
16 410 411 412 412 412 413 int8eq eqsel eqjoinsel ));
DATA(insert OID = 411 (PGNSP PGUID b f 20 20
16 411 410 0 0 0 0 int8ne neqsel neqjoinsel ));
--- 128,136
DATA(insert OID = 389 ( !! PGNSP PGUID l f 0 20
1700 0 0 0 0 0 0 numeric_fac - - ));
DATA(insert OID = 385 (
Re: [PATCHES] [BUGS] Bug#333854: pg_group file update problems
This bug will be fixed in the next 8.0.X release. I have not fixed
7.4.X because the risk/benefit does not warrant it, and 8.1 does not
have this problem.
---
Bruce Momjian wrote:
I have developed a small patch to 8.0.X that fixes your reported
problem:
test= CREATE GROUP g1;
CREATE GROUP
test= CREATE USER u1 IN GROUP g1;
CREATE USER
test= \! cat /u/pg/data/global/pg_group
g1u1
test= CREATE USER u2 IN GROUP g1;
CREATE USER
test= \! cat /u/pg/data/global/pg_group
g1u1 u2
test= ALTER USER u2 RENAME TO u3;
ALTER USER
test= \! cat /u/pg/data/global/pg_group
g1u1 u3
In the patch, notice the old comment that suggests we might need to use
CommandCounterIncrement().
This sesms safe to apply to back branches.
---
Dennis Vshivkov wrote:
Package: postgresql-8.0
Version: 8.0.3-13
Severity: important
Tags: patch, upstream
Here's the problem:
db=# CREATE GROUP g1;
CREATE GROUP
db=# CREATE USER u1 IN GROUP g1;(1)
CREATE USER
# cat /var/lib/postgresql/8.0/main/global/pg_group
#
The file gets rewritten, but the group `g1' line does not get
added to the file. Continue:
db=# CREATE USER u2 IN GROUP g1;(2)
CREATE USER
# cat /var/lib/postgresql/8.0/main/global/pg_group
g1u1
#
Now the line is there, but it lacks the latest member. Consider
this also:
db=# ALTER USER u2 RENAME TO u3;(3)
ALTER USER
# cat /var/lib/postgresql/8.0/main/global/pg_group
g1u1 u2
#
The problem is that the code that updates pg_group file resolves
group membership through the system user catalogue cache. The
file update happens shortly before the commit, but the caches
only see updates after the commit. Because of this, new users
or changes in users' names often do not make it to pg_group.
That leads to mysterious authentication failures subsequently.
The problem can also have security implications for certain
pg_hba.conf arrangements.
The attached `98-6-pg_group-stale-data-fix.patch' makes the code
in question access the system user table directly and thus fixes
the cases (1) and (2), however (3) is doubly ill: the user
renaming code does not even trigger a pg_group file update.
Hence the other patch, `98-5-rename-user-update-pg_group.patch'.
A byproduct of the main fix is removal of an unlikely system
cache reference leak which happens if a group member name
contains a newline.
The problems were found and the fixes were done for PostgreSQL
8.0.3 release. The flaws seem intact in 8.0.4 source code, too.
Hope this helps.
--
/Awesome Walrus [EMAIL PROTECTED]
[ Attachment, skipping... ]
[ Attachment, skipping... ]
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/backend/commands/user.c
===
RCS file: /cvsroot/pgsql/src/backend/commands/user.c,v
retrieving revision 1.147
diff -c -c -r1.147 user.c
*** src/backend/commands/user.c 31 Dec 2004 21:59:42 - 1.147
--- src/backend/commands/user.c 14 Oct 2005 15:42:17 -
***
*** 175,183
/*
* Read pg_group and write the file. Note we use SnapshotSelf to
! * ensure we see all effects of current transaction. (Perhaps could
! * do a CommandCounterIncrement beforehand, instead?)
*/
scan = heap_beginscan(grel, SnapshotSelf, 0, NULL);
while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
{
--- 175,183
/*
* Read pg_group and write the file. Note we use SnapshotSelf to
! * ensure we see all effects of current transaction.
*/
+ CommandCounterIncrement();
scan = heap_beginscan(grel, SnapshotSelf, 0, NULL);
while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
{
***
*** 781,786
--- 781,787
* Set flag to update flat password file at commit.
*/
user_file_update_needed();
+ group_file_update_needed();
}
***
*** 1200,1205
--- 1201,1207
* Set flag to update flat password file at commit.
*/
user_file_update_needed();
+ group_file_update_needed();
}
Re: [PATCHES] [HACKERS] expanded \df+ display broken in beta4
Michael Paesold wrote:
Bruce Momjian wrote:
Michael Paesold wrote:
Tom Lane wrote:
Michael Paesold [EMAIL PROTECTED] writes:
Robert Treat wrote:
ISTM even a GUC to enable/disable would have been better scheme than
what we have now; we are basically leaving no options for those who
found the old behavior useful, while what we had before would at least
let people switch back and forth.
I think Robert is right here and the new behaviour is a step backwards.
Should we revert the patch for the time being, and take another go at it
in 8.2?
One idea is to hack \d not to honor \x, and let the others honor it.
That would probably hit most of the cases people will use in 8.1.
In fact, \d is pretty special because it is more of a group of outputs,
unlike \df, which is a single table output.
+1 from me. That seems like a workable compromise and should probably
meet the needs of the author of the patch to change the \x behavior.
OK, here is a patch that disables expanded output only for \d tablename.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/bin/psql/common.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/common.c,v
retrieving revision 1.108
diff -c -c -r1.108 common.c
*** src/bin/psql/common.c 15 Oct 2005 02:49:40 - 1.108
--- src/bin/psql/common.c 27 Oct 2005 05:03:11 -
***
*** 795,802
{
printQueryOpt my_popt = pset.popt;
- my_popt.topt.normal_query = true;
-
/* write output to \g argument, if any */
if (pset.gfname)
{
--- 795,800
Index: src/bin/psql/describe.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/describe.c,v
retrieving revision 1.128
diff -c -c -r1.128 describe.c
*** src/bin/psql/describe.c 20 Oct 2005 05:15:09 - 1.128
--- src/bin/psql/describe.c 27 Oct 2005 05:03:12 -
***
*** 703,708
--- 703,711
retval = false;
+ /* This output looks confusing in expanded mode. */
+ myopt.disableExpanded = true;
+
initPQExpBuffer(buf);
initPQExpBuffer(title);
initPQExpBuffer(tmpbuf);
Index: src/bin/psql/print.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/print.c,v
retrieving revision 1.78
diff -c -c -r1.78 print.c
*** src/bin/psql/print.c15 Oct 2005 02:49:40 - 1.78
--- src/bin/psql/print.c27 Oct 2005 05:03:12 -
***
*** 1491,1497
* normal (user-submitted) query, not a table we're printing for a slash
* command.
*/
! if (opt-expanded opt-normal_query)
use_expanded = true;
else
use_expanded = false;
--- 1491,1497
* normal (user-submitted) query, not a table we're printing for a slash
* command.
*/
! if (opt-expanded !opt-disableExpanded)
use_expanded = true;
else
use_expanded = false;
Index: src/bin/psql/print.h
===
RCS file: /cvsroot/pgsql/src/bin/psql/print.h,v
retrieving revision 1.29
diff -c -c -r1.29 print.h
*** src/bin/psql/print.h15 Oct 2005 02:49:40 - 1.29
--- src/bin/psql/print.h27 Oct 2005 05:03:12 -
***
*** 43,50
* decimal
marker */
char *tableAttr; /* attributes for HTML table ... */
int encoding; /* character encoding */
! boolnormal_query; /* are we presenting the results of a
normal
!* query, or a
slash command? */
} printTableOpt;
--- 43,49
* decimal
marker */
char *tableAttr; /* attributes for HTML table ... */
int encoding; /* character encoding */
! booldisableExpanded;/* Should we honor \x? Not for \d. */
} printTableOpt;
Index: src/bin/psql/startup.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/startup.c,v
retrieving revision 1.125
diff -c -c -r1.125 startup.c
*** src/bin/psql/startup.c 15 Oct 2005 02:49:40 - 1.125
--- src/bin/psql/startup.c 27 Oct 2005 05:03:12 -
***
*** 147,153
pset.queryFout = stdout;
pset.popt.topt.border = 1;
pset.popt.topt.pager = 1;
!
