Re: [HACKERS] Proposal for psql wildcarding behavior w/schemas
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: 1. A wildcardable pattern must consist of either namepattern or namepattern.namepattern. Regarding the use of quotes: Would \d foo.bar show the table foo.bar, whereas \d foo.bar would show the table bar in schema foo? That'd be my interpretation of what it should do. Okay with you? regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] IRIX and large SMP: donations of shells c
I'm going to be overseeing a move from a Mac-based postgres database (100k transactions/day, roughly 5M rows) to an SGI Octane in the near-ish term.The machine will only be two-way SMP. I'd like to see it working 64-bit and compiled with MIPSpro. I have a friend who has mostly succeeded in getting it compiiled with MIPSpro, but Neil told me today there might be concerns with SMP systems 4cpu's. I offered access on a system with 6 cpus (SGI Challenge L, R4400's). I may have access to other machines, including a 36-cpu Octane with R10k's. If this is useful to somebody on the core group, please let me know. I'd really like to see Postgres understand MIPSpro and irix out of the box. I understand there is some difficulty at present. I'd appreciate a Cc on the thread, if possible. Thanks, alex ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] IRIX and large SMP: donations of shells c
Alex Avriette [EMAIL PROTECTED] writes: I'd really like to see Postgres understand MIPSpro and irix out of the box. I understand there is some difficulty at present. Like what? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] IRIX and large SMP: donations of shells c
Alex Avriette [EMAIL PROTECTED] writes: I have a friend who has mostly succeeded in getting it compiiled with MIPSpro, but Neil told me today there might be concerns with SMP systems 4cpu's. That's my impression, anyone -- I can't say I've confirmed that with any benchmarks. I offered access on a system with 6 cpus (SGI Challenge L, R4400's). As I indicated in IRC, I'd be interested in the use of that machine. If that's okay, can you send me the auth info via email? You can find my GPG key on keyserver.net. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Locale number format confusion
It seems we need a smart plan for handling the decimal point vs. comma
issue. Observe: (lc_numeric = de_DE)
create table test_f (x double precision);
CREATE TABLE
insert into test_f values ('1.5');
ERROR: Bad float8 input format '1.5'
insert into test_f values ('1,5');
INSERT 16909 1
create table test_n (x numeric);
CREATE TABLE
insert into test_n values ('1.5');
INSERT 16915 1
insert into test_n values ('1,5');
ERROR: Bad numeric input format '1,5'
create table test_p (x point);
CREATE TABLE
insert into test_p values ('(1.5, 2.4)');
ERROR: Bad point external representation '(1.5, 2.4)'
insert into test_p values ('(1,5, 2,4)');
INSERT 16918 1
insert into test_p values ('(9,5)');
ERROR: Bad point external representation '(9,5)'
peter=# insert into test_p values ('(9,5,1)');
INSERT 16919 1
select * from test_p;
x
---
(1,5,2,4)
(9,5,1)-- (What point is that?)
(Yes, we really need structured types, not the parse-your-own-string
extension interface.)
SQL99 effectively says that a decimal *point* should be used for casts
from numerical to character types and vice versa. (You can read about
this in 6.22 GR 6b, 7b, 8a, 8b -- there are pretty specific rules for
converting numbers to strings which we probably don't follow very
strictly.)
I propose that we do this (probably by writing our own strtod and
friends). If you want to format your numbers to local convention,
to_char() can be used.
Comments?
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Linux Largefile Support In Postgresql RPMS
Note, I'm not sure this belongs in -hackers so I've added -general but left -hackers in so that list can at least see that it's going to -general. On Thu, 8 Aug 2002, mark Kirkwood wrote: Hi all, I just spent some of the morning helping a customer build Pg 7.2.1 from source in order to get Linux largefile support in pg_dump etc. They possibly would have kept using the binary RPMs if they had this feature. This got me to wondering why the Redhat/Mandrake...etc binary RPMS are built without it. Would including default largefile support in Linux RPMs be a good idea ? (I am presuming that such RPMs are built by the Pg community and supplied to the various distros... apologies if I have this all wrong...) I must admit that I am fairly new to PostgreSQL but I have used it and read stuff about it and I'm not sure what you mean. Could you explain what you did? A quick scan of the source shows that there may be an issue in storage/file/buffile.c:BufFileSeek() is that the sort of thing you are talking about? Or maybe I've got it completely wrong and you're talking about adding code to pg_dump although I thought that could already handle large objects. Actually, I'm going to shut up now before I really do show my ignorance and let you answer. -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] postgresql performance tuning document ?
Again, I'm not sure this doesn't belong on -general but have left the -hackers in the distribution list so it can be seen there. On Fri, 9 Aug 2002, Oleg Bartunov wrote: I see files truncated at 1Gb on my Linux server: -rw---1 postgres users855490560 Aug 6 20:53 795261707.2 -rw---1 postgres users943259648 Aug 8 23:34 823049708 -rw---1 postgres users1073741824 Aug 6 20:53 795261707.1 -rw---1 postgres users1073741824 Aug 6 20:53 795261707 I'm wondering if postgresql doesn't have LARGE_FILES support ? Those look like PostgreSQL's data files (from the context of the email) is that so? And if so, have you got a requirement for having large data files? It seems an odd requirement especially as I'd say you have approaching 3GB in one table so you're not too far off getting to 4GB and can the host system handle such files? -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] postgresql performance tuning document ?
On Thu, 8 Aug 2002, Nigel J. Andrews wrote: I see files truncated at 1Gb on my Linux server: -rw---1 postgres users855490560 Aug 6 20:53 795261707.2 -rw---1 postgres users943259648 Aug 8 23:34 823049708 -rw---1 postgres users1073741824 Aug 6 20:53 795261707.1 -rw---1 postgres users1073741824 Aug 6 20:53 795261707 I'm wondering if postgresql doesn't have LARGE_FILES support ? I'm a user not a hacker but I seem to remember a discussion on this before. Part of the design was to break the files at approx. 1GByte partly or wholly to avoid any OS file size limitation. Rod -- Open Source Software - Sometimes you get more than you paid for... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Locale number format confusion
Peter Eisentraut [EMAIL PROTECTED] writes: I propose that we do this (probably by writing our own strtod and friends). If you want to format your numbers to local convention, to_char() can be used. Why are we allowing LC_NUMERIC to become active at all? IMHO this is a bug that you have recently introduced ... just take that code out again. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib/ltree, pls, apply patch
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Teodor Sigaev wrote: The patch solves this problem, I hope... Christopher Kings-Lynne wrote: I'm still getting ltree failures on 64bit freebsd: sed 's,MODULE_PATHNAME,$libdir/ltree,g' ltree.sql.in ltree.sql gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPI C -DLOWER_NODE -I. -I../../src/include -c -o ltree_io.o ltree_io.c -MMD ltree_io.c: In function `ltree_in': ltree_io.c:57: warning: int format, different type arg (arg 3) ltree_io.c:63: warning: int format, different type arg (arg 4) ltree_io.c:68: warning: int format, different type arg (arg 3) ltree_io.c:78: warning: int format, different type arg (arg 4) ltree_io.c: In function `lquery_in': ltree_io.c:185: warning: int format, different type arg (arg 3) ltree_io.c:193: warning: int format, different type arg (arg 3) ltree_io.c:197: warning: int format, different type arg (arg 3) ltree_io.c:202: warning: int format, different type arg (arg 3) ltree_io.c:207: warning: int format, different type arg (arg 3) ltree_io.c:217: warning: int format, different type arg (arg 4) ltree_io.c:226: warning: int format, different type arg (arg 4) ltree_io.c:231: warning: int format, different type arg (arg 3) ltree_io.c:233: warning: int format, different type arg (arg 3) ltree_io.c:243: warning: int format, different type arg (arg 3) ltree_io.c:251: warning: int format, different type arg (arg 3) ltree_io.c:260: warning: int format, different type arg (arg 3) ltree_io.c:265: warning: int format, different type arg (arg 3) ltree_io.c:273: warning: int format, different type arg (arg 3) ltree_io.c:279: warning: int format, different type arg (arg 3) ltree_io.c:296: warning: int format, different type arg (arg 4) I think it's to do with the printf % thingy used in the elog... Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Teodor Sigaev [EMAIL PROTECTED] [ application/gzip is not supported, skipping... ] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Another python patch -- minor
Picked up. Thanks. --- Greg Copeland wrote: Checking application/pgp-signature: FAILURE -- Start of PGP signed section. On Wed, 2002-08-07 at 23:00, Christopher Kings-Lynne wrote: Hi Greg, You should be submitting all these patches to the pgsql-patches mailing list... Should I resubmit all my patches to that list or will they all be picked up from here? Greg -- End of PGP section, PGP failed! -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] CLUSTER and indisclustered
Tom Lane dijo: Bruce Momjian [EMAIL PROTECTED] writes: Tom, should we be updating that flag after we CLUSTER instead of requiring an ANALYZE after the CLUSTER? Could do that I suppose, but I'm not super-excited about it. ANALYZE is quite cheap these days (especially in comparison to CLUSTER ;-)). I'd settle for a note in the CLUSTER docs that recommends a subsequent ANALYZE --- this seems no different from recommending ANALYZE after bulk data load or other major update of a table. What if I [try to] extend the grammar to support an additional ANALYZE in CLUSTER, so that it analyzes the table automatically? Say CLUSTER index ON table [ANALYZE]; Or maybe just do an analyze of the table automatically after the CLUSTERing. What does everybody think? -- Alvaro Herrera (alvherre[a]atentus.com) Para tener mas hay que desear menos ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] CLUSTER and indisclustered
Alvaro Herrera [EMAIL PROTECTED] writes: What if I [try to] extend the grammar to support an additional ANALYZE in CLUSTER, so that it analyzes the table automatically? I don't like this -- it seems like bloat. What's the advantage of CLUSTER foo ON bar ANALYZE; over CLUSTER foo ON bar; ANALYZE; Or maybe just do an analyze of the table automatically after the CLUSTERing. Hmmm... I don't really see the problem with adding a note in the docs suggesting that users following a CLUSTER with an ANALYZE (of course, that assumes that the CLUSTER will significantly change the ordering of the data in the table, which isn't always the case -- which is another reason why make this automatic seems unwarranted, IMHO). It seems like you're looking for a solution to a non-existent problem. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Documentation BuildLog
http://developer.postgresql.org/docs/postgres/buildlog.html It would appear that the files point to the old urls, not the new ones as per the cvs segregation. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On 8 Aug 2002, Hannu Krosing wrote: The main difference (in the inheritance part) is that a relation does not have one fixed set of fields, but can have any additional fields added in inherited tables and still be part of to the base table as well. This is trivial to do with a view. Actually I am not against ripping out the current broken implementation, but not before there has been a new, correct model available for at least two releses, so that people have had time to switch over. So in other words, you want to let people use broken stuff, rather than switch to another method, currently available, that has all of the functionality but is not broken. I guess that's an opinion, all right. VIEWs are broken too, in the sense that you can't insert into them without doing some hard work. Views are missing functionality. That is rather different from making other tables lie about what they contain, essentially destroying the requested data integrity. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
Curt Sampson wrote: On 8 Aug 2002, Hannu Krosing wrote: The main difference (in the inheritance part) is that a relation does not have one fixed set of fields, but can have any additional fields added in inherited tables and still be part of to the base table as well. This is trivial to do with a view. And views of this sort are trivial to do using PG's OO extensions. I think I see a trend in this thread. Why not give it up, dude? -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Thu, 8 Aug 2002, Don Baccus wrote: And views of this sort are trivial to do using PG's OO extensions. So long as you don't mind them being broken, yeah. But hell, when someone asks for a unique constraint, they probably don't really mean it, do they? And what's wrong with multiple records with the same primary key? It's clear to me now I've been working from the wrong direction; we should leave the OO stuff and delete the relational stuff from the database instead. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PITR, checkpoint, and local relations
On Wed, 2002-08-07 at 23:41, Tom Lane wrote: J. R. Nield [EMAIL PROTECTED] writes: The xlog code must allow us to force an advance to the next log file, and truncate the archived file when it's copied so as not to waste space. Uh, why? Why not just force a checkpoint and remember the exact location of the checkpoint within the current log file? If I do a backup with PITR and save it to tape, I need to be able to restore it even if my machine is destroyed in a fire, and all the logs since the end of a backup are destroyed. If we don't allow the user to force a log advance, how will he do this? I don't want to copy the log file, and then have the original be written to later, because it will become confusing as to which log file to use. Is the complexity really that big of a problem with this? When and if you roll back to a prior checkpoint, you'd want to start the system running forward with a new xlog file, I think (compare what pg_resetxlog does). But it doesn't follow that you MUST force an xlog file boundary simply because you're taking a backup. This complicates both the recovery logic and XLogInsert, and I'm trying to kill the last latent bug in that feature now. Indeed. How about keeping it simple, instead? regards, tom lane -- J. R. Nield [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] CLUSTER and indisclustered
Neil Conway dijo: Alvaro Herrera [EMAIL PROTECTED] writes: What if I [try to] extend the grammar to support an additional ANALYZE in CLUSTER, so that it analyzes the table automatically? I don't like this -- it seems like bloat. Maybe you are right. Or maybe just do an analyze of the table automatically after the CLUSTERing. Hmmm... I don't really see the problem with adding a note in the docs suggesting that users following a CLUSTER with an ANALYZE (...). ANALYZE is an inexpensive operation (compared to CLUSTER, anyway), so it can't hurt to have it done automatically. -- Alvaro Herrera (alvherre[a]atentus.com) Linux transformó mi computadora, de una `máquina para hacer cosas', en un aparato realmente entretenido, sobre el cual cada día aprendo algo nuevo (Jaime Salinas) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
Curt Sampson wrote: On Thu, 8 Aug 2002, Don Baccus wrote: And views of this sort are trivial to do using PG's OO extensions. So long as you don't mind them being broken, yeah. But hell, when someone asks for a unique constraint, they probably don't really mean it, do they? Good grief, we all agree that they're currently broken and need to be fixed someday. Give it up. You're being a boor. -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] CLUSTER and indisclustered
Or maybe just do an analyze of the table automatically after the CLUSTERing. Hmmm... I don't really see the problem with adding a note in the docs suggesting that users following a CLUSTER with an ANALYZE (...). ANALYZE is an inexpensive operation (compared to CLUSTER, anyway), so it can't hurt to have it done automatically. Well we have previously had discussions on the topic of adding analyze to the end of dumps, etc. and the result has always been in favour of keeping the command set orthogonal and not doing an automatic analyze... Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] CLUSTER and indisclustered
Christopher Kings-Lynne dijo: Or maybe just do an analyze of the table automatically after the CLUSTERing. Well we have previously had discussions on the topic of adding analyze to the end of dumps, etc. and the result has always been in favour of keeping the command set orthogonal and not doing an automatic analyze... Oh. Sorry for the noise. I'm trying to look at other things in the TODO so I stop pestering about CLUSTER. -- Alvaro Herrera (alvherre[a]atentus.com) Pensar que el espectro que vemos es ilusorio no lo despoja de espanto, sólo le suma el nuevo terror de la locura (Perelandra, CSLewis) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] CLUSTER and indisclustered
Well we have previously had discussions on the topic of adding analyze to the end of dumps, etc. and the result has always been in favour of keeping the command set orthogonal and not doing an automatic analyze... Oh. Sorry for the noise. I'm trying to look at other things in the TODO so I stop pestering about CLUSTER. All I can say is - thanks for fixing CLUSTER. As soon as we upgrade to 7.3 I'm going on a CLUSTERing spree :) Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] CLUSTER and indisclustered
If you're looking for something very useful to work on, see if Gavin Sherry(?) can post his old CREATE OR REPLACE VIEW code. I'm pretty sure he (or someone) said that he had an old patch, that needed to be synced with HEAD... This functionality is pretty essential for 7.3... Chris -Original Message- From: Alvaro Herrera [mailto:[EMAIL PROTECTED]] Sent: Friday, 9 August 2002 10:21 AM To: Christopher Kings-Lynne Cc: Neil Conway; Tom Lane; Bruce Momjian; [EMAIL PROTECTED] Subject: Re: [HACKERS] CLUSTER and indisclustered Christopher Kings-Lynne dijo: Or maybe just do an analyze of the table automatically after the CLUSTERing. Well we have previously had discussions on the topic of adding analyze to the end of dumps, etc. and the result has always been in favour of keeping the command set orthogonal and not doing an automatic analyze... Oh. Sorry for the noise. I'm trying to look at other things in the TODO so I stop pestering about CLUSTER. -- Alvaro Herrera (alvherre[a]atentus.com) Pensar que el espectro que vemos es ilusorio no lo despoja de espanto, sólo le suma el nuevo terror de la locura (Perelandra, CSLewis) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] CLUSTER and indisclustered
Neil Conway [EMAIL PROTECTED] writes: Alvaro Herrera [EMAIL PROTECTED] writes: What if I [try to] extend the grammar to support an additional ANALYZE in CLUSTER, so that it analyzes the table automatically? I don't like this -- it seems like bloat. My reaction exactly. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PITR, checkpoint, and local relations
J. R. Nield [EMAIL PROTECTED] writes: Uh, why? Why not just force a checkpoint and remember the exact location of the checkpoint within the current log file? If I do a backup with PITR and save it to tape, I need to be able to restore it even if my machine is destroyed in a fire, and all the logs since the end of a backup are destroyed. And for your next trick, restore it even if the backup tape itself is destroyed. C'mon, be a little reasonable here. The backups and the log archive tapes are *both* critical data in any realistic view of the world. Is the complexity really that big of a problem with this? Yes, it is. Didn't you just admit to struggling with bugs introduced by exactly this complexity?? I don't care *how* spiffy the backup scheme is, if when push comes to shove my backup doesn't restore because there was a software bug in the backup scheme. In this context there simply is not any virtue greater than simple and reliable. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Linux Largefile Support In Postgresql RPMS
On Thursday 08 August 2002 05:36 pm, Nigel J. Andrews wrote: Matt Kirkwood wrote: I just spent some of the morning helping a customer build Pg 7.2.1 from source in order to get Linux largefile support in pg_dump etc. They possibly would have kept using the binary RPMs if they had this feature. And you added this by doing what, exactly? I'm not familiar with pg_dump largefile support as a standalone feature. (I am presuming that such RPMs are built by the Pg community and supplied to the various distros... apologies if I have this all wrong...) You have this wrong. The distributions do periodically sync up with my revision, and I with theirs, but they do their own packaging. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] pg_stat_reset() weirdness
Hi guys, If you apply the pg_stat_reset() function patch you get this regression failure. Is this because it's returning a bool I guess? Shall I just fix the regression test to exclude this function? Chris *** ./expected/opr_sanity.out Fri Jul 19 07:11:32 2002 --- ./results/opr_sanity.outFri Aug 9 13:26:00 2002 *** *** 27,34 AND p1.proname !~ 'costestimate$' AND p1.proname != 'update_pg_pwd_and_pg_group'; oid | proname ! -+- ! (0 rows) -- Look for conflicting proc definitions (same names and input datatypes). -- (This test should be dead code now that we have the unique index --- 27,35 AND p1.proname !~ 'costestimate$' AND p1.proname != 'update_pg_pwd_and_pg_group'; oid |proname ! --+--- ! 2249 | pg_stat_reset ! (1 row) -- Look for conflicting proc definitions (same names and input datatypes). -- (This test should be dead code now that we have the unique index == ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
