date:20020815

Re: [HACKERS] Open 7.3 items

2002-08-15 Thread Mike Mascari


Joe Conway wrote:
 
 Hannu Krosing wrote:
  What about functions
 
  1. split(text,text,int) returns text
 
  2. split(text,text) returns text[]
 
  and why not
 
  3. split(text,text,text) returns text
 
  which returns text from $1 delimited by $2 and $3
 
 Given the time remaining before beta, I'll be happy just to get #1 done.
 
 I can see the utility of #2 (or perhaps even a table function which
 breaks the string into individual rows). I'm not sure I understand #3.
 
 I am concerned about the name though -- only in that there are usually
 objections raised to function names that are too likely to conflict with
 user created function names. But split is good from the standpoint
 that it is used in other languages, so people should find it familiar.
 
 Anyone have comments on the name?

Actually, I've been wondering if it wouldn't be a good idea with schemas
coming to think now about how to divide up namespaces for all sorts of
things, including PostgreSQL's built in functions, the contrib code,
etc. I think a naming scheme with which both PostgreSQL and the
community would comply, a la Java's reverse DNS scheme for namespaces
would be neat. So when a database is installed, the following schemas
are automatically created:

org.postgresql.system - System tables and core functions
org.postgresql.text - Text related functions
org.postgresql.math - Math related functions
org.postgresql.fts - Full-Text schema

or perhaps:

org.postgresql.contrib.fts - Full-Text schema

etc.

I don't even know if . is allowed in the schema names, but you get the
idea. Then, a users search_path (or whatever it's called, I haven't used
the development version in a while), would be the equivalent of Java's
import statement, or C++'s using statement. So split would be a
function in the org.postgresql.text schema.

How about them apples?

If this is an insane idea, its 3:32 A.M. my time ;-)

Mike Mascari
[EMAIL PROTECTED]

 
 Joe

---(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] tsearch bug in 7.2.1?

2002-08-15 Thread Oleg Bartunov


tsearch has compiled-in stop-list, it's currently just not flexible
as OpenFTS does. We plan to move most functionality to tsearch but
currently have no time. Feel free to join us to speedup tsearch
development.

Oleg

On Thu, 15 Aug 2002, Christopher Kings-Lynne wrote:

 Actually, looking at this again it's possible that tsearch sees 'a' as a
 skip word and so doesn't allow a search on it.  This makes it _really_ hard
 for me to parse and check user keywords - maybe a 'isvalidsyntax' sort of
 function should be included?  Hmmm...maybe I could use the cast to
 ::mquery_txt to check it...but now I have to detect an ERROR condition and
 deal with it appropriately...

 Chris

  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]]On Behalf Of Christopher
  Kings-Lynne
  Sent: Thursday, 15 August 2002 1:43 PM
  To: Hackers
  Subject: [HACKERS] tsearch bug in 7.2.1?
 
 
  Hi,
 
  I noticed this behaviour:
 
  usa=# SELECT rr.id, rr.name, rr.description FROM recipe_recipes rr WHERE
  rr.ftiidx ## 's';
   id  |   name   |
  description
  -+--+-
  --
  
   202 | Bird's Nest  | An egg nestled in a crispy, hot
  bread roll.
   293 | Reuben Triple S  | Corn beef, swiss cheese and
  sauerkraut on pumpernickel.
30 | Hedgehogs| This is comfort food at it's
  yummiest.
   130 | Hearty Apple  Cinnamon Porridge | A great way to warm you up on a
  winter's morning.
83 | Banana  Apple Compote   | Great way to finish a meal on a
  cool winter's day.
   139 | Minestrone   | Served with a crusty roll, this
  soup is a meal on it's own.
75 | Mango Sorbet | A mango-lover's delight.
19 | Chunky Vegetable Chowder | Serve this soup with a
  crusty roll
  and it's a hearty meal on a cold winter's eve.
36 | Lemon Fish Rolls | A pleasant way to
  include fish in
  your family's diet.
  (9 rows)
 
  usa=# SELECT rr.id, rr.name, rr.description FROM recipe_recipes rr WHERE
  rr.ftiidx ## 's|a';
  ERROR:  Your query contained only stopword(s), ignored
  usa=# SELECT rr.id, rr.name, rr.description FROM recipe_recipes rr WHERE
  rr.ftiidx ## 's|x';
   id  |   name   |
  description
  -+--+-
  --
  
   202 | Bird's Nest  | An egg nestled in a crispy, hot
  bread roll.
   293 | Reuben Triple S  | Corn beef, swiss cheese and
  sauerkraut on pumpernickel.
30 | Hedgehogs| This is comfort food at it's
  yummiest.
   130 | Hearty Apple  Cinnamon Porridge | A great way to warm you up on a
  winter's morning.
83 | Banana  Apple Compote   | Great way to finish a meal on a
  cool winter's day.
   139 | Minestrone   | Served with a crusty roll, this
  soup is a meal on it's own.
75 | Mango Sorbet | A mango-lover's delight.
19 | Chunky Vegetable Chowder | Serve this soup with a
  crusty roll
  and it's a hearty meal on a cold winter's eve.
36 | Lemon Fish Rolls | A pleasant way to
  include fish in
  your family's diet.
  (9 rows)
  usa=# SELECT rr.id, rr.name, rr.description FROM recipe_recipes rr WHERE
  rr.ftiidx ## 'st|a';
  ERROR:  Your query contained only stopword(s), ignored
  usa=# SELECT rr.id, rr.name, rr.description FROM recipe_recipes rr WHERE
  rr.ftiidx ## 'st|ar';
   id | name | description
  +--+-
  (0 rows)
 
  I don't see how that's correct?  Those ERRORs seem to be valid syntax to
  me...
 
  Chris
 
 
  ---(end of broadcast)---
  TIP 2: you can get off all lists at once with the unregister command
  (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
 


 ---(end of broadcast)---
 TIP 4: Don't 'kill -9' the postmaster


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


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] tsearch bug in 7.2.1?

2002-08-15 Thread Christopher Kings-Lynne


 tsearch has compiled-in stop-list, it's currently just not flexible
 as OpenFTS does. We plan to move most functionality to tsearch but
 currently have no time. Feel free to join us to speedup tsearch
 development.

Unfortunately I'm just as time-deprived :(

Chris


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Open 7.3 issues

2002-08-15 Thread Emmanuel Charpentier


Christopher Kings-Lynne wrote:

[ ... ]

 What about this.
 
 1. Implement pg_get_foreignkey_def() or whatever
 2. Adjust pg_dump to dump foreign keys using an ALTER statement
 3. Back port the above to rel 7_2_2
 4. Release a 7.2.2 version and ask that people upgrade to that version and
 do a dump before they upgrade to 7.3.
 5. All is well, plus ppl who don't want to switch to 7.3 on production get
 all sorts of useful bug fixes as well.

If we have to have a 7.2.2 release, I'd like to suggest to backport 
create or replace view , it it doesn't use any 7.3-specific feature. 
This one is my pet peeve at the moment ... ;-) Would give a *lot* of 
end-user functionality (and I am a and-user, after all), at little cost, 
if I'm not mistaken ...).

--
Emmanuel Charpeentier


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

[HACKERS] pg_dump large file support

2002-08-15 Thread Oliver Elphick


I've implemented large file support for pg_dump, in what I hope is a
portable fashion.  Please review the attached patch.

This needs an additional option from autoconf, because pg_dump prints a
hex offset which needs to be either %Lx or %llx, but there is no hex
equivalent to INT64_FORMAT.  To get this working I have arbitrarily
defined OFF_T_FORMATX as %lld, but that needs to be changed before the
patch is incorporated.

Peter E suggested that there was no need for the macro definitions in
pg_backup.h but I wasn't clear how else to achieve what was needed.


-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight, UK
http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 Praying always with all prayer and supplication in the
  Spirit, and watching thereunto with all perseverance 
  and supplication for all saints.   Ephesians 6:18


Index: src/bin/pg_dump/Makefile
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/pg_dump/Makefile,v
retrieving revision 1.36
diff -u -r1.36 Makefile
--- src/bin/pg_dump/Makefile	2002/07/27 20:10:05	1.36
+++ src/bin/pg_dump/Makefile	2002/08/15 10:31:53
@@ -18,6 +18,8 @@
 
 override CPPFLAGS := -I$(libpq_srcdir) $(CPPFLAGS)
 
+CFLAGS +=  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
+
 all: submake-libpq submake-libpgport pg_dump pg_restore pg_dumpall
 
 pg_dump: pg_dump.o common.o $(OBJS) $(libpq_builddir)/libpq.a 
Index: src/bin/pg_dump/pg_backup.h
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/pg_dump/pg_backup.h,v
retrieving revision 1.20
diff -u -r1.20 pg_backup.h
--- src/bin/pg_dump/pg_backup.h	2002/07/04 15:35:07	1.20
+++ src/bin/pg_dump/pg_backup.h	2002/08/15 10:31:53
@@ -27,6 +27,25 @@
 
 #include libpq-fe.h
 
+/*
+ * Large file support
+ */
+
+#ifdef _LARGEFILE_SOURCE
+ #define FSEEK fseeko
+ #define FTELL ftello
+ #define OFF_T_FORMAT INT64_FORMAT
+ #define OFF_T_FORMATX %llx/* needs an autoconf setting */
+ typedef off_t OFF_T;
+#else
+ #define FSEEK fseek
+ #define FTELL ftell
+ #define OFF_T_FORMAT %ld
+ #define OFF_T_FORMATX %lx
+ typedef long int OFF_T;
+#endif
+
+
 #define atooid(x)  ((Oid) strtoul((x), NULL, 10))
 #define oidcmp(x,y) ( ((x)  (y) ? -1 : ((x)  (y)) ?  1 : 0) )
 #define oideq(x,y) ( (x) == (y) )
Index: src/bin/pg_dump/pg_backup_archiver.c
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/pg_dump/pg_backup_archiver.c,v
retrieving revision 1.53
diff -u -r1.53 pg_backup_archiver.c
--- src/bin/pg_dump/pg_backup_archiver.c	2002/08/10 16:57:31	1.53
+++ src/bin/pg_dump/pg_backup_archiver.c	2002/08/15 10:31:55
@@ -1561,7 +1561,7 @@
 	}
 
 	/* If we can't seek, then mark the header as read */
-	if (fseek(fh, 0, SEEK_SET) != 0)
+	if (FSEEK(fh, 0, SEEK_SET) != 0)
 	{
 		/*
 		 * NOTE: Formats that use the looahead buffer can unset this in
Index: src/bin/pg_dump/pg_backup_custom.c
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/pg_dump/pg_backup_custom.c,v
retrieving revision 1.19
diff -u -r1.19 pg_backup_custom.c
--- src/bin/pg_dump/pg_backup_custom.c	2002/05/29 01:38:56	1.19
+++ src/bin/pg_dump/pg_backup_custom.c	2002/08/15 10:31:56
@@ -81,13 +81,13 @@
 	char	   *zlibIn;
 	int			inSize;
 	int			hasSeek;
-	int			filePos;
+	OFF_T			filePos;
 	int			dataStart;
 } lclContext;
 
 typedef struct
 {
-	int			dataPos;
+	OFF_T			dataPos;
 	int			dataLen;
 } lclTocEntry;
 
@@ -99,7 +99,7 @@
 static void _readBlockHeader(ArchiveHandle *AH, int *type, int *id);
 static void _StartDataCompressor(ArchiveHandle *AH, TocEntry *te);
 static void _EndDataCompressor(ArchiveHandle *AH, TocEntry *te);
-static int	_getFilePos(ArchiveHandle *AH, lclContext *ctx);
+static OFF_T	_getFilePos(ArchiveHandle *AH, lclContext *ctx);
 static int	_DoDeflate(ArchiveHandle *AH, lclContext *ctx, int flush);
 
 static char *modulename = gettext_noop(custom archiver);
@@ -188,7 +188,7 @@
 		if (!AH-FH)
 			die_horribly(AH, modulename, could not open archive file %s: %s\n, AH-fSpec, strerror(errno));
 
-		ctx-hasSeek = (fseek(AH-FH, 0, SEEK_CUR) == 0);
+		ctx-hasSeek = (FSEEK(AH-FH, 0, SEEK_CUR) == 0);
 
 	}
 	else
@@ -201,7 +201,7 @@
 		if (!AH-FH)
 			die_horribly(AH, modulename, could not open archive file %s: %s\n, AH-fSpec, strerror(errno));
 
-		ctx-hasSeek = (fseek(AH-FH, 0, SEEK_CUR) == 0);
+		ctx-hasSeek = (FSEEK(AH-FH, 0, SEEK_CUR) == 0);
 
 		ReadHead(AH);
 		ReadToc(AH);
@@ -285,7 +285,7 @@
 {
 	lclTocEntry *ctx = (lclTocEntry *) te-formatData;
 
-	ahprintf(AH, -- Data Pos: %d (Length %d)\n, ctx-dataPos, ctx-dataLen);
+	ahprintf(AH, -- Data Pos:  INT64_FORMAT  (Length %d)\n, ctx-dataPos, ctx-dataLen);
 }
 
 /*
@@ -486,7 +486,7 @@

Re: [HACKERS] pg_dump large file support

2002-08-15 Thread Oliver Elphick


On Thu, 2002-08-15 at 11:41, Oliver Elphick wrote:
 I've implemented large file support for pg_dump, in what I hope is a
 portable fashion.  Please review the attached patch.

 Index: src/bin/pg_dump/Makefile
 ===
 RCS file: /projects/cvsroot/pgsql-server/src/bin/pg_dump/Makefile,v
 retrieving revision 1.36
 diff -u -r1.36 Makefile
 --- src/bin/pg_dump/Makefile  2002/07/27 20:10:05 1.36
 +++ src/bin/pg_dump/Makefile  2002/08/15 10:31:53
 @@ -18,6 +18,8 @@
  
  override CPPFLAGS := -I$(libpq_srcdir) $(CPPFLAGS)
  
 +CFLAGS +=  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
 +

I just realised this is the wrong place to put this definition, since it
will act unconditonally and attempt to compile large file support even
where it is not available.  This too ought to come from autoconf, I
think.

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight, UK
http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 Praying always with all prayer and supplication in the
  Spirit, and watching thereunto with all perseverance 
  and supplication for all saints.   Ephesians 6:18


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] Open 7.3 issues

2002-08-15 Thread Patrick Welche


On Thu, Aug 15, 2002 at 12:09:00AM -0400, Neil Conway wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
... 
  integrate or remove new libpqxx
  integrate or add to gborg Pg:DBD
  
  Seems like gborg is the place for these.
 
 Yes, but I'd also like to see libpq++, perl5, and possibly some other
 interfaces re-packaged separately. I think everyone agrees on the
 direction here, it just needs someone (Marc?) to do the work.

Would the method of use be
- checkout postgresql
- cd pgsql/src/interfaces
- checkout libpq++ from gborg
- cd ../..
- configure --with-CXX

or would libpq++ become more removed.. (configure options to libpq++ to
point to the rest or pgsql?)

Cheers,

Patrick
(prefer former)

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] Open 7.3 items

2002-08-15 Thread Tom Lane


Mike Mascari [EMAIL PROTECTED] writes:
 I don't even know if . is allowed in the schema names,

It isn't, and we couldn't invent such a scheme without seriously
diverging from SQL compliance: the next naming level up from schemas is
reserved for catalogs (think databases).  I don't know that we'll ever
support cross-database access, but we shouldn't foreclose the
possibility in pursuit of a naming scheme that doesn't really add very
much value.

You could possibly fake it with schema names like org_postgresql_foo,
but I can't get very excited about that ...

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

Re: [HACKERS] contrib Makefiles

2002-08-15 Thread Bruce Momjian



Yes, you can optionally specify the symbol to find in the *.so file as
part of the CREATE FUNCTION command.

---

Tom Lane wrote:
 Christopher Kings-Lynne [EMAIL PROTECTED] writes:
  I guess my question would be that currently fulltextindex generates SQL like
  this:
 
  create function fti() returns opaque as
  '$libdir/fti'
  language 'C';
 
  So it references the fti.so, but where does it say what function to actually
  run in fti.so?  Or is it assumed in C functions that the function to call in
  the shared object is the same as the name of the function???
 
 That's the assumption unless you specify differently.  Time to reread
 the CREATE FUNCTION man page ...
 
   regards, tom lane
 
 ---(end of broadcast)---
 TIP 4: Don't 'kill -9' the postmaster
 

-- 
  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 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] Standard replication interface?

2002-08-15 Thread Greg Copeland


Well, that's a different issue.  ;)

I initially wanted to get feedback to see if anyone else thought the
concept might hold some merit.

I take it from your answer you think it might...but are scratching your
head wondering exactly what it entails...

Greg


On Wed, 2002-08-14 at 22:47, Tom Lane wrote:
 Greg Copeland [EMAIL PROTECTED] writes:
  ... it occurred to me that a predefined set of views
  and/or tables for all replication implementations may be worthwhile.
 
 Do we understand replication well enough to define such a set of views?
 I sure don't ...
 
   regards, tom lane




signature.asc
Description: This is a digitally signed message part

Re: [HACKERS] Open 7.3 items

2002-08-15 Thread Michael Meskes


On Sun, Aug 11, 2002 at 11:12:57AM -0400, Tom Lane wrote:
  Not solved yet. And it's just a matter of time until we run into it with
  the main parser grammar file as well.
 
 Yeah, I've been worrying about that too.  Any idea how close we are to
 trouble in the main grammar?

No idea. The ecpg grammar in the main tree has about 530 rules, while my
actual version is at nearly 550. The main grammar should be at about
440. So there's some room left.

 Plan C would be to devote some work to minimizing the number of states
 in the main grammar (I assume it's number of states that's the problem).
 I doubt anyone's ever tried, so there might be enough low-hanging fruit
 to get ecpg off the hook for awhile.

Actually I already ate the really low-hanging fruit. :-)

I did spend some time to reduce the states, albeit surely not to the
extent possible, but still it will mean quite some work I'm afraid.

Michael

P.S.: No repsonse by bison upstream yet, but I think he's on vacation
this week.

-- 
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Open 7.3 issues

2002-08-15 Thread Lamar Owen


On Thursday 15 August 2002 12:28 am, Tom Lane wrote:
 I think that's likely to be a hard sell.  The most we are likely to get
 is to ask people to use the 7.3 pg_dump to dump their 7.2 server when
 they are about to upgrade to 7.3 --- even that much is a difficult trick
 for RPM users.

It's more of a difficult trick for the RPM maintainer :-)

No, I've thought about this possibility, and I can see packaging a 
'postgresql-pg_dump73-7.2.1' RPM consisting entirely of the 7.3 pg_dump 
linked against the pieces of 7.2.1 necessary.  Ugly, but doable.

I know I sound like a broken record (for those who remember vinyl records), 
but good upgrading tools would eliminate this recurring problem.  That's all 
I'm saying about that this time -- I've said enough, and it's all archived 
for those who care to know what I think about the state of upgrading.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Standard replication interface?

2002-08-15 Thread Andrew Sullivan


On Wed, Aug 14, 2002 at 10:15:32PM -0500, Greg Copeland wrote:

 Reading about the pgmonitor thread and mention of gborg made me wonder
 about replication and ready ability to uniformly monitor it.  Just as
 pg_stat* tables exist to allow for statistic gathering and monitoring in
 a uniform fashion, it occurred to me that a predefined set of views
 and/or tables for all replication implementations may be worthwhile. 
 That way, no matter what replication method/tool is being used, as long
 as it conforms to the defined replication interfaces, generic monitoring
 tools can be used to keep an eye on things.

That sounds like the cart is before the horse.  You need to know what
sort of replication scheme you might ever have before you could
know the statistics that you might want to know.

There are different sorts of replication schemes under consideration. 
For instance, rserv uses an asynchronous master/slave approach, which
relies on slaves that are almost dumb as chickens.  (Not quite. 
There is some data about the state of replication in the slave
database; but most of it is in the master.)  Postgres-R, on the other
hand, contemplates a distributed model wherein different database
machines participate in a pool.

So for rserv-style replication, you want to know (for instance)
average slave-update times, and whether slaves are getting behind,
and by how much, and such.  Balancing of inserts, however, is not
relevant, because you can't do that.

Postgres-R will have the opposite need: you'll want to know what sort
of load balancing you're getting, but time-to-replicate is not
relevant, because a commit on one machine is necessarily a commit
everywhere (that's why it's eager replication).

You probably could design a set of statistics that would cover all
cases, but only after you know what the cases were.

A

-- 

Andrew Sullivan   87 Mowat Avenue 
Liberty RMS   Toronto, Ontario Canada
[EMAIL PROTECTED]  M6K 3E3
 +1 416 646 3304 x110


---(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] Companies involved in development

2002-08-15 Thread Bruce Momjian


I think we are going to see more company-funded developers working on
PostgreSQL.  There are a handful now, but I can see lots more coming.
I am going to work on getting those funding companies more visibility. 
We originally were concerned that such involvement may harm the
development process, but history has shown that it has only been a huge
benefit for the community.

-- 
  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] Companies involved in development

2002-08-15 Thread Hans-Jürgen Schönig


I think it would be a huge benefit for the community to have some more 
company-funding. This would lead to the implementation of some features 
people need urgently (replication in the core and so forth). On the 
other hand a better product makes even more developers work for 
PostgreSQL. We were thinking of funding the project as well and seems to 
be a good way of improving the product we make our living of. We have 
also tried to get some government funding we could invest into 
PostgreSQL but unfornately all we could get was EUR 10k which is some 
kind of ridiculous. We should have invested much more but it is just not 
possible at this point so we dropped the idea.
For a company PostgreSQL definitely is an interesting area to invest 
because it has proven to be a good product and there are just minor 
things (sync. replication - eg. Postgres-R) missing to make it a real 
enterprise database. The support of the community of more than just 
optimal and it is an interesting subject.
Talking about practical experience: Our customers love PostgreSQL. The 
only thing they miss is 24x7 availability due to a lack of hot-failover 
and replication. A way to tweak the optimizer better (some have SQL 
statements being 2 pages long).
We have done quite a lot of Oracle up to now but in many respects 
PostgreSQL seems to be the better product but in the case of 
availability we fail. The database never crashes but it is just to hard 
to make a cluster out of it - we have to do it on an application level 
and too many people worry about conistency if one node fails.

Also: It would be interesting to have a special section on the website 
where people can post that they need money to implement something really 
useful. I guess there'd be a lot of people who'd pay for replication or 
things like that if they knew more.
By the way; many people seem to think that PostgreSQL is GPL license. I 
know it is easy to find out what it means and that it is now that way 
but we should explain what BSD license REALLY means in just a few words. 
This may sound ridiculous but people just don't look for information.

All in all I think that there are ways to find people contributing 
financially to the project.

Regards,
Hans-Jürgen Schönig


Bruce Momjian wrote:

I think we are going to see more company-funded developers working on
PostgreSQL.  There are a handful now, but I can see lots more coming.
I am going to work on getting those funding companies more visibility. 
We originally were concerned that such involvement may harm the
development process, but history has shown that it has only been a huge
benefit for the community.
  



-- 
*Cybertec Geschwinde u Schoenig*
Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
Tel: +43/1/913 68 09; +43/664/233 90 75
www.postgresql.at http://www.postgresql.at, cluster.postgresql.at 
http://cluster.postgresql.at, www.cybertec.at 
http://www.cybertec.at, kernel.cybertec.at http://kernel.cybertec.at


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] Companies involved in development

2002-08-15 Thread Bruce Momjian



I will add something about the BSD license to the advocacy web page I am
trying to put together.  My list is:

  P O S T G R E S Q L
A D V O C A C Y


Current at ftp://candle.pha.pa.us/pub/postgresql/advocacy.

Quotations
Company users
Beef up developers list, add companies
success stories
update developers map
BSD license


---

Hans-Jürgen Schönig wrote:
 I think it would be a huge benefit for the community to have some more 
 company-funding. This would lead to the implementation of some features 
 people need urgently (replication in the core and so forth). On the 
 other hand a better product makes even more developers work for 
 PostgreSQL. We were thinking of funding the project as well and seems to 
 be a good way of improving the product we make our living of. We have 
 also tried to get some government funding we could invest into 
 PostgreSQL but unfornately all we could get was EUR 10k which is some 
 kind of ridiculous. We should have invested much more but it is just not 
 possible at this point so we dropped the idea.
 For a company PostgreSQL definitely is an interesting area to invest 
 because it has proven to be a good product and there are just minor 
 things (sync. replication - eg. Postgres-R) missing to make it a real 
 enterprise database. The support of the community of more than just 
 optimal and it is an interesting subject.
 Talking about practical experience: Our customers love PostgreSQL. The 
 only thing they miss is 24x7 availability due to a lack of hot-failover 
 and replication. A way to tweak the optimizer better (some have SQL 
 statements being 2 pages long).
 We have done quite a lot of Oracle up to now but in many respects 
 PostgreSQL seems to be the better product but in the case of 
 availability we fail. The database never crashes but it is just to hard 
 to make a cluster out of it - we have to do it on an application level 
 and too many people worry about conistency if one node fails.
 
 Also: It would be interesting to have a special section on the website 
 where people can post that they need money to implement something really 
 useful. I guess there'd be a lot of people who'd pay for replication or 
 things like that if they knew more.
 By the way; many people seem to think that PostgreSQL is GPL license. I 
 know it is easy to find out what it means and that it is now that way 
 but we should explain what BSD license REALLY means in just a few words. 
 This may sound ridiculous but people just don't look for information.
 
 All in all I think that there are ways to find people contributing 
 financially to the project.
 
 Regards,
 Hans-J?rgen Sch?nig
 
 
 Bruce Momjian wrote:
 
 I think we are going to see more company-funded developers working on
 PostgreSQL.  There are a handful now, but I can see lots more coming.
 I am going to work on getting those funding companies more visibility. 
 We originally were concerned that such involvement may harm the
 development process, but history has shown that it has only been a huge
 benefit for the community.
   
 
 
 
 -- 
 *Cybertec Geschwinde u Schoenig*
 Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
 Tel: +43/1/913 68 09; +43/664/233 90 75
 www.postgresql.at http://www.postgresql.at, cluster.postgresql.at 
 http://cluster.postgresql.at, www.cybertec.at 
 http://www.cybertec.at, kernel.cybertec.at http://kernel.cybertec.at
 
 
 ---(end of broadcast)---
 TIP 5: Have you checked our extensive FAQ?
 
 http://www.postgresql.org/users-lounge/docs/faq.html
 

-- 
  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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

[HACKERS] Alter table add foreign key

2002-08-15 Thread Stephan Szabo



I'm planning on trying out a version
of the check done for foreign keys that does
a query on the fktable with a NOT EXISTS
subselect rather than the current run the
trigger for each row (thus doing one query
per row of the table). I want to see if this
tends to be faster than what we're doing now
and want to make sure noone has any general
objections to doing it this way (before
bothering to do it and timings).



---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Open 7.3 items

2002-08-15 Thread Bruce Momjian



OK, no one complained/commented on my idea of having global users have a
trailing '@', so here is a patch that implements that.  It has the
advantages of:

no special install user (create global user before enabling feature)
no /data/PG_INSTALLER file
allows multiple global users to be easily added
no namespace collisions because globals have a trailing @
easy for postmaster to recognize global users
no double-user lookups of pg_pwd changes
very small patch footprint

The only downside is that it treats '@' as a special character when it
is enabled, but frankly, because we are appending @dbname anyway, having
'@' as a special character in that case makes sense.

Comments?

---

Bruce Momjian wrote:
 Tom Lane wrote:
  Bruce Momjian [EMAIL PROTECTED] writes:
   I don't know where else to go with the patch at this point.  I think
   increasing the number of 'global' users is polluting the namespace too
   much,
  
  Why?  If the installation needs N global users, then it needs N global
  users; who are you to make that value judgment for them?
  
  In practice I think an installation that's using this feature is going
  to have a pretty small number of global users, and so the issue of
  collisions with local usernames isn't really as big as it's been painted
  in this thread.  We could ignore that issue (except for documenting it)
  and have a perfectly serviceable feature.
 
 The original idea was that Marc wanted people who could create their own
 users for their own databases.  If we make the creation of global users
 too easy, all of a sudden people don't have control over their db
 usernames because they have to avoid all the global user names already
 defined.  By adding multiple global users, it is diluting the usefulness
 of the feature.
 
 I suppose a pg_global_users file would be a compromise because only the
 admin could actually add people to that file.  If it was more automatic,
 like writing pg_shadow, someone could create a user without an @ and
 block access for other users to other database, which is bad.
 
 I still don't like the fact that people think they have control over
 their db namespace, when they really don't, but no one else seems to see
 that as a problem.  The namespace conflicts just yell of poor design.
 
 OK, I have another idea.  What if we make global users end with an @, so
 dave@ is a global user.  We can easily check for that in the postmaster
 and not append the dbname.  I know it makes @ a special character, but
 considering the problem of namespace collision, it seems better than
 what we have now.  We could add the install user too if we wish, or just
 tell them to make sure they add a user@ before turning on the feature.
 
 -- 
   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 6: Have you searched our list archives?
 
 http://archives.postgresql.org
 

-- 
  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


Index: doc/src/sgml/runtime.sgml
===
RCS file: /cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.125
diff -c -r1.125 runtime.sgml
*** doc/src/sgml/runtime.sgml   15 Aug 2002 14:26:15 -  1.125
--- doc/src/sgml/runtime.sgml   15 Aug 2002 15:32:29 -
***
*** 1191,1196 
--- 1191,1211 
   /varlistentry
  
   varlistentry
+   termvarnameDB_USER_NAMESPACE/varname (typeboolean/type)/term
+   listitem
+para
+ Appends literal@/ and the database name to the user name when
+ connecting to the database.  This allows per-database users.  
+ User names ending with literal@/ are considered global and may 
+ connect to any database.  It is recommended you create at least one 
+ global user, e.g. literalpostgres@/, before enabling this feature.  
+ Also, when creating user names containing literal@/, you will need 
+ to quote the user name.
+/para
+   /listitem
+  /varlistentry
+ 
+  varlistentry
indexterm
 primarydeadlock/primary
 secondarytimeout/secondary
Index: src/backend/libpq/auth.c
===
RCS file: /cvsroot/pgsql-server/src/backend/libpq/auth.c,v
retrieving revision 1.82
diff -c -r1.82 auth.c
*** src/backend/libpq/auth.c20 Jun 2002 20:29:28 -  1.82
---

Re: [HACKERS] Open 7.3 issues

2002-08-15 Thread Bruce Momjian



Actually, my _big_ question is whether the lack of dependency info
coming from 7.2 is going to cause problems in 7.3, i.e. do we make
assumptions that dependency info is there and in cases it isn't, are
there surprises for users, where things worked fine in 7.2.  I want to
know if there are cases where we assumed dependency info was there when
in 7.2 we handled the lack of depenency better.

---

Tom Lane wrote:
 Christopher Kings-Lynne [EMAIL PROTECTED] writes:
  What about this.
  1. Implement pg_get_foreignkey_def() or whatever
  2. Adjust pg_dump to dump foreign keys using an ALTER statement
  3. Back port the above to rel 7_2_2
  4. Release a 7.2.2 version and ask that people upgrade to that version and
  do a dump before they upgrade to 7.3.
 
 The trouble with this is that 7.2.2 would include a lot of rather poorly
 tested code (code that has not even made it to CVS yet) ... and if
 there's a problem in that code, it breaks dump files whether you are an
 early upgrader to 7.3 or not.
 
 I think that's likely to be a hard sell.  The most we are likely to get
 is to ask people to use the 7.3 pg_dump to dump their 7.2 server when
 they are about to upgrade to 7.3 --- even that much is a difficult trick
 for RPM users.
 
 The other problem is that given a 7.2 system catalog setup, it's not
 really any easier to reconstruct this is a foreign key on the server
 side than it is to do it on the pg_dump side.  So if we can figure out
 how to do it at all, we might as well make pg_dump do the work instead
 of insisting on a server update.
 
   regards, tom lane
 

-- 
  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 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] Open 7.3 items

2002-08-15 Thread Vince Vielhaber


On Thu, 15 Aug 2002, Bruce Momjian wrote:


 OK, no one complained/commented on my idea of having global users have a
 trailing '@', so here is a patch that implements that.  It has the
 advantages of:

Probably because not everyone saw it.  I know I didn't.  This entire
issue is growing more and more complex.  How about a configure item
to not even compile it in?  Or better yet, a configure item to put
it there with the default off.

Vince.
-- 
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
 56K Nationwide Dialup from $16.00/mo at Pop4 Networking
  http://www.camping-usa.com  http://www.cloudninegifts.com
   http://www.meanstreamradio.com   http://www.unknown-artists.com
==




---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Open 7.3 items

2002-08-15 Thread Bruce Momjian

Vince, you were in the CC, and it went to hackers:

Message 772/835 Bruce Momjian   
Aug 14, 2002 08:30:47 pm -0400
Subject: Re: [HACKERS] Open 7.3 items
To: Tom Lane [EMAIL PROTECTED]
Date: Wed, 14 Aug 2002 20:30:47 -0400 (EDT)
cc: Lamar Owen [EMAIL PROTECTED], Vince Vielhaber [EMAIL PROTECTED],
   PostgreSQL-development [EMAIL PROTECTED]
X-Virus-Scanned: by AMaViS new-20020517
Precedence: bulk
Sender: [EMAIL PROTECTED]
X-Virus-Scanned: by AMaViS new-20020517

---

Vince Vielhaber wrote:
 On Thu, 15 Aug 2002, Bruce Momjian wrote:

  OK, no one complained/commented on my idea of having global users have a
  trailing '@', so here is a patch that implements that.  It has the
  advantages of:

 Probably because not everyone saw it.  I know I didn't.  This entire
 issue is growing more and more complex.  How about a configure item
 to not even compile it in?  Or better yet, a configure item to put
 it there with the default off.

 Vince.
 -- 
 ==
 Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
  56K Nationwide Dialup from $16.00/mo at Pop4 Networking
   http://www.camping-usa.com  http://www.cloudninegifts.com
http://www.meanstreamradio.com   http://www.unknown-artists.com
 ==

-- 
  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 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] Open 7.3 items

2002-08-15 Thread Bruce Momjian


Vince Vielhaber wrote:
 On Thu, 15 Aug 2002, Bruce Momjian wrote:
 
 
  OK, no one complained/commented on my idea of having global users have a
  trailing '@', so here is a patch that implements that.  It has the
  advantages of:
 
 Probably because not everyone saw it.  I know I didn't.  This entire
 issue is growing more and more complex.  How about a configure item
 to not even compile it in?  Or better yet, a configure item to put
 it there with the default off.

I think I am prety close, and I don't see a configure flag as any better
than a GUC option that is off by default.

-- 
  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 6: Have you searched our list archives?

http://archives.postgresql.org

[HACKERS] failure notice (fwd)

2002-08-15 Thread Vince Vielhaber



Who the hell are these people and why can't they configure their
own MTA?

Vince.
-- 
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
 56K Nationwide Dialup from $16.00/mo at Pop4 Networking
  http://www.camping-usa.com  http://www.cloudninegifts.com
   http://www.meanstreamradio.com   http://www.unknown-artists.com
==



-- Forwarded message --
Date: 15 Aug 2002 16:47:22 -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: failure notice

Hi. This is the qmail-send program at ic.kharkov.ua.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

[EMAIL PROTECTED]:
Connected to 192.204.191.242 but sender was rejected.
Remote host said: 550 5.0.0 Go away, your mailserver is broken

--- Below this line is a copy of the message.

Return-Path: [EMAIL PROTECTED]
Received: (qmail 62268 invoked from network); 15 Aug 2002 16:46:47 -
Received: from dialup44.kharkov.ukrpack.net (HELO dual.shena.ic.kharkov.ua) 
(212.1.112.156)
  by mail.ic.kharkov.ua with SMTP; 15 Aug 2002 16:46:47 -
Received: from dual.shena.ic.kharkov.ua (DUAL [172.16.200.1]) by 
dual.shena.ic.kharkov.ua with SMTP (Microsoft Exchange Internet Mail Service Version 
5.5.2448.0)
id Q926YA3A; Thu, 15 Aug 2002 19:46:07 +0300
Received: by dual.shena.ic.kharkov.ua (Microsoft Exchange Connector for POP3 Mailboxes 
4.50.2113) with SMTP (Global POP3 Download)
 id [EMAIL PROTECTED]; Thu, 15 Aug 2002 19:45:56 
+0300
Return-Path: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 61671 invoked by alias); 15 Aug 2002 16:39:03 -
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 61668 invoked from network); 15 Aug 2002 16:39:03 -
Received: from postgresql.org (64.49.215.8)
  by mail.ic.kharkov.ua with SMTP; 15 Aug 2002 16:39:03 -
Received: from localhost (postgresql.org [64.49.215.8])
by postgresql.org (Postfix) with ESMTP
id 419EF47654E; Thu, 15 Aug 2002 12:38:48 -0400 (EDT)
Received: from postgresql.org (postgresql.org [64.49.215.8])
by postgresql.org (Postfix) with SMTP
id A2668475F2D; Thu, 15 Aug 2002 12:38:47 -0400 (EDT)
Received: from localhost (postgresql.org [64.49.215.8])
by postgresql.org (Postfix) with ESMTP id EE137475974
for [EMAIL PROTECTED]; Thu, 15 Aug 2002 12:38:44 -0400 (EDT)
Received: from paprika.michvhf.com (adsl-67-36-71-182.dsl.sfldmi.ameritech.net 
[67.36.71.182])
by postgresql.org (Postfix) with SMTP id DCB8947594D
for [EMAIL PROTECTED]; Thu, 15 Aug 2002 12:38:43 -0400 (EDT)
Received: (qmail 55151 invoked by uid 1001); 15 Aug 2002 16:38:45 -
Date: Thu, 15 Aug 2002 12:38:45 -0400 (EDT)
From: Vince Vielhaber [EMAIL PROTECTED]
To: Bruce Momjian [EMAIL PROTECTED]
Cc: Tom Lane [EMAIL PROTECTED], Lamar Owen [EMAIL PROTECTED],
PostgreSQL-development [EMAIL PROTECTED]
Subject: Re: [HACKERS] Open 7.3 items
In-Reply-To: [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by AMaViS new-20020517
Precedence: bulk
Sender: [EMAIL PROTECTED]
X-Virus-Scanned: by AMaViS new-20020517

On Thu, 15 Aug 2002, Bruce Momjian wrote:

 Vince Vielhaber wrote:
  On Thu, 15 Aug 2002, Bruce Momjian wrote:
 
  
   OK, no one complained/commented on my idea of having global users have a
   trailing '@', so here is a patch that implements that.  It has the
   advantages of:
 
  Probably because not everyone saw it.  I know I didn't.  This entire
  issue is growing more and more complex.  How about a configure item
  to not even compile it in?  Or better yet, a configure item to put
  it there with the default off.

 I think I am prety close, and I don't see a configure flag as any better
 than a GUC option that is off by default.

But how many people would even use it?  I can't see adding the bloat
unnecessarily and risking it accidently being turned on.  Am I wrong
and really alot of people actually want/need this?

Vince.
-- 
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
 56K Nationwide Dialup from $16.00/mo at Pop4 Networking
  http://www.camping-usa.com  http://www.cloudninegifts.com
   http://www.meanstreamradio.com   http://www.unknown-artists.com
==




---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command

Re: [HACKERS] Open 7.3 issues

2002-08-15 Thread Tom Lane


Bruce Momjian [EMAIL PROTECTED] writes:
 coming from 7.2 is going to cause problems in 7.3, i.e. do we make
 assumptions that dependency info is there and in cases it isn't, are
 there surprises for users, where things worked fine in 7.2.  I want to
 know if there are cases where we assumed dependency info was there when
 in 7.2 we handled the lack of depenency better.

No, we have not broken any cases that used to work, AFAIK.

There are new features in 7.3 that will not work in a database made from
a 7.2 dump --- for example, dropping an old table containing a serial
column won't make the sequence go away, because we won't have a
dependency link between the table and the sequence.  But it didn't go
away in 7.2 either, so the behavior's no worse.  Another thing we won't
understand is that certain sets of triggers make up a foreign-key
constraint, so you won't be able to use ALTER TABLE DROP CONSTRAINT to
delete 'em.  But you couldn't in 7.2 either.

While I've toyed with the notion of trying to intuit these dependencies
as we reload a database, I'm not at all sure it's a good idea.  The
former 7.2 user might be quite unhappy if we drop a sequence he wasn't
expecting to have dropped.  We cannot tell for certain how the sequence
was made --- it might have been handmade and then used in an explicit
DEFAULT expression, in which case an auto-drop dependency would probably
not be a friendly thing to spring on the user.

The bulk of the new dependencies are made automatically as we handle
CREATE statements, so they'll be correct in a reloaded database anyway.
AFAIR it's just serial sequences and foreign keys that are not going to
be as bright as they might be.

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

Re: [HACKERS] Open 7.3 issues

2002-08-15 Thread Bruce Momjian


Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
  coming from 7.2 is going to cause problems in 7.3, i.e. do we make
  assumptions that dependency info is there and in cases it isn't, are
  there surprises for users, where things worked fine in 7.2.  I want to
  know if there are cases where we assumed dependency info was there when
  in 7.2 we handled the lack of depenency better.
 
 No, we have not broken any cases that used to work, AFAIK.
 
 There are new features in 7.3 that will not work in a database made from
 a 7.2 dump --- for example, dropping an old table containing a serial
 column won't make the sequence go away, because we won't have a
 dependency link between the table and the sequence.  But it didn't go
 away in 7.2 either, so the behavior's no worse.  Another thing we won't
 understand is that certain sets of triggers make up a foreign-key
 constraint, so you won't be able to use ALTER TABLE DROP CONSTRAINT to
 delete 'em.  But you couldn't in 7.2 either.
 
 While I've toyed with the notion of trying to intuit these dependencies
 as we reload a database, I'm not at all sure it's a good idea.  The
 former 7.2 user might be quite unhappy if we drop a sequence he wasn't
 expecting to have dropped.  We cannot tell for certain how the sequence
 was made --- it might have been handmade and then used in an explicit
 DEFAULT expression, in which case an auto-drop dependency would probably
 not be a friendly thing to spring on the user.
 
 The bulk of the new dependencies are made automatically as we handle
 CREATE statements, so they'll be correct in a reloaded database anyway.
 AFAIR it's just serial sequences and foreign keys that are not going to
 be as bright as they might be.

OK, that's what I needed to know.  It may be confusing to some users
that 7.2 serial/foreign keys don't auto-drop while 7.3 do.  We need to
mention that in the release notes.  I think that will be enough, but I
can imagine people dumping/reloading their db's to get that dependency,
and I am not sure how we would tell them to do that.

-- 
  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] Open 7.3 items

2002-08-15 Thread Vince Vielhaber


On Thu, 15 Aug 2002, Bruce Momjian wrote:


 Vince, you were in the CC, and it went to hackers:

Oh, I'm not saying I didn't get it, I'm saying I didn't see it in
the message.  It looked as if you were only replying to Tom so after
reading the jist of it I moved on.  When you included it a little
while ago I wondered what you were referring to so I read the whole
thing more carefully and realized that I missed the end.

Vince.
-- 
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
 56K Nationwide Dialup from $16.00/mo at Pop4 Networking
  http://www.camping-usa.com  http://www.cloudninegifts.com
   http://www.meanstreamradio.com   http://www.unknown-artists.com
==




---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] Open 7.3 items

2002-08-15 Thread Vince Vielhaber


On Thu, 15 Aug 2002, Bruce Momjian wrote:

 Vince Vielhaber wrote:
  On Thu, 15 Aug 2002, Bruce Momjian wrote:
 
  
   OK, no one complained/commented on my idea of having global users have a
   trailing '@', so here is a patch that implements that.  It has the
   advantages of:
 
  Probably because not everyone saw it.  I know I didn't.  This entire
  issue is growing more and more complex.  How about a configure item
  to not even compile it in?  Or better yet, a configure item to put
  it there with the default off.

 I think I am prety close, and I don't see a configure flag as any better
 than a GUC option that is off by default.

But how many people would even use it?  I can't see adding the bloat
unnecessarily and risking it accidently being turned on.  Am I wrong
and really alot of people actually want/need this?

Vince.
-- 
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
 56K Nationwide Dialup from $16.00/mo at Pop4 Networking
  http://www.camping-usa.com  http://www.cloudninegifts.com
   http://www.meanstreamradio.com   http://www.unknown-artists.com
==




---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Open 7.3 items

2002-08-15 Thread Bruce Momjian


Vince Vielhaber wrote:
 On Thu, 15 Aug 2002, Bruce Momjian wrote:
 
  Vince Vielhaber wrote:
   On Thu, 15 Aug 2002, Bruce Momjian wrote:
  
   
OK, no one complained/commented on my idea of having global users have a
trailing '@', so here is a patch that implements that.  It has the
advantages of:
  
   Probably because not everyone saw it.  I know I didn't.  This entire
   issue is growing more and more complex.  How about a configure item
   to not even compile it in?  Or better yet, a configure item to put
   it there with the default off.
 
  I think I am prety close, and I don't see a configure flag as any better
  than a GUC option that is off by default.
 
 But how many people would even use it?  I can't see adding the bloat
 unnecessarily and risking it accidently being turned on.  Am I wrong
 and really alot of people actually want/need this?

Well, the demand seems to be larger than I thought, considering the
number of people who have chimed in and want certain features, like
multiple global users.  I see this being using more by ISP's and
universities that need better user/db partitioning.

-- 
  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 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] Standard replication interface?

2002-08-15 Thread Greg Copeland


On Thu, 2002-08-15 at 09:47, Andrew Sullivan wrote:
 On Wed, Aug 14, 2002 at 10:15:32PM -0500, Greg Copeland wrote:
  That way, no matter what replication method/tool is being used, as long
  as it conforms to the defined replication interfaces, generic monitoring
  tools can be used to keep an eye on things.
 
 That sounds like the cart is before the horse.  You need to know what
 sort of replication scheme you might ever have before you could
 know the statistics that you might want to know.

Hmmm.  Never heard of an inquiry for interest in a concept as putting
the cart before the horse.  Considering this is pretty much how things
get developed in the real world, I'm not sure what you feel is so
special about replication.

First step is always identify the need.  I'm attempting to do so.  Not
sure what you'd consider the first step to be but I can assure you,
regardless of this concept seeing the light of day, it is the first
step.  The horse is correctly positioned in front of the cart.

I also stress that I'm talking about a statistical replication
interface.  It occurred to me that you might of been confused on this
matter.  That is, a set of tables and views will allow for the
replication process to be uniformly *monitored*.  I am not talking about
a set of interfaces which all manner of replication much perform its job
through (interface with databases for replication).

 
 There are different sorts of replication schemes under consideration. 

Yep.  Thus it would seemingly be ideal to have a specification which
different implementations would seek to implement.  Off of the top of my
head and for starters, a table and/or view which could can queried that
returns the tables that are being replicated sounds good to me.  Same
thing for the list of databases, the servers involved and their
associated role (master, slave, peer).

Without such a concept, there will be no standardized way to monitor
your replication.  As such, chances are one of two things will happen. 
One, a single replication method will be championed and fair tools will
develop to support where all others are bastards.  Two, quality tools to
monitor replication will never materialize because each method for
monitoring is specific to the different types of implementations. 
Resources will constantly be spread amongst a variety of well meaning
projects.


--Greg





signature.asc
Description: This is a digitally signed message part

Re: [HACKERS] Open 7.3 items

2002-08-15 Thread Vince Vielhaber


On Thu, 15 Aug 2002, Bruce Momjian wrote:

 Vince Vielhaber wrote:
  On Thu, 15 Aug 2002, Bruce Momjian wrote:
 
   Vince Vielhaber wrote:
On Thu, 15 Aug 2002, Bruce Momjian wrote:
   

 OK, no one complained/commented on my idea of having global users have a
 trailing '@', so here is a patch that implements that.  It has the
 advantages of:
   
Probably because not everyone saw it.  I know I didn't.  This entire
issue is growing more and more complex.  How about a configure item
to not even compile it in?  Or better yet, a configure item to put
it there with the default off.
  
   I think I am prety close, and I don't see a configure flag as any better
   than a GUC option that is off by default.
 
  But how many people would even use it?  I can't see adding the bloat
  unnecessarily and risking it accidently being turned on.  Am I wrong
  and really alot of people actually want/need this?

 Well, the demand seems to be larger than I thought, considering the
 number of people who have chimed in and want certain features, like
 multiple global users.  I see this being using more by ISP's and
 universities that need better user/db partitioning.

I don't know that concern over a possible limited number of global
users is directly proportional to the desire for the feature.

Vince.
-- 
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
 56K Nationwide Dialup from $16.00/mo at Pop4 Networking
  http://www.camping-usa.com  http://www.cloudninegifts.com
   http://www.meanstreamradio.com   http://www.unknown-artists.com
==




---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] Open 7.3 items

2002-08-15 Thread Tom Lane


Bruce Momjian [EMAIL PROTECTED] writes:
 + /* We append database name if db_user_namespace true. */
 + #define SM_DATABASE_USER (SM_DATABASE+SM_USER)

Is this calculation correct?  I'd think you'd need at least one more
character to allow for the @.  And I'm not sure about whether trailing
nulls are or need to be counted.  There seem to be some places in your
patch where things are dimensioned SM_DATABASE_USER and some where it's
SM_DATABASE_USER+1; why the inconsistency, and which is right?

Other than getting the array sizes right, it does look like a nice
patch; very small, which is what I'd hoped for.  The notion of having to
say postgres@ still seems kinda ugly, but given the simplicity of the
patch I'm willing to live with that.

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] Open 7.3 items

2002-08-15 Thread Vince Vielhaber


On Thu, 15 Aug 2002, Tom Lane wrote:

 Other than getting the array sizes right, it does look like a nice
 patch; very small, which is what I'd hoped for.  The notion of having to
 say postgres@ still seems kinda ugly, but given the simplicity of the
 patch I'm willing to live with that.

Going from postgres to postgres@ ???  I don't care how simple the patch
is, I'd rather it was configurable to keep it out completely.  That's
not just ugly, that's coyote ugly!

Vince.
-- 
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
 56K Nationwide Dialup from $16.00/mo at Pop4 Networking
  http://www.camping-usa.com  http://www.cloudninegifts.com
   http://www.meanstreamradio.com   http://www.unknown-artists.com
==




---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Open 7.3 items

2002-08-15 Thread Lamar Owen


On Thursday 15 August 2002 11:54 am, Bruce Momjian wrote:
 OK, no one complained/commented on my idea of having global users have a
 trailing '@', so here is a patch that implements that.  It has the
 advantages of:

As it's substantially the same as user@template1, I am of course OK with it. 
:-)  Easier to type than user@template1, too.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Open 7.3 items

2002-08-15 Thread Tom Lane


Vince Vielhaber [EMAIL PROTECTED] writes:
 Going from postgres to postgres@ ???  I don't care how simple the patch
 is, I'd rather it was configurable to keep it out completely.  That's
 not just ugly, that's coyote ugly!

Yeah, but it doesn't affect you unless you turn on the GUC parameter.
Most people will never even know this code is there.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Open 7.3 items

2002-08-15 Thread Vince Vielhaber


On Thu, 15 Aug 2002, Tom Lane wrote:

 Vince Vielhaber [EMAIL PROTECTED] writes:
  Going from postgres to postgres@ ???  I don't care how simple the patch
  is, I'd rather it was configurable to keep it out completely.  That's
  not just ugly, that's coyote ugly!

 Yeah, but it doesn't affect you unless you turn on the GUC parameter.
 Most people will never even know this code is there.

But it doesn't need to affect anyone, even if it's enabled.  Isn't
the lack of an @ just as good as an @ at the end of the username?
Gets rid of the ugliness and won't break things if it's suddenly
enabled.

Vince.
-- 
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
 56K Nationwide Dialup from $16.00/mo at Pop4 Networking
  http://www.camping-usa.com  http://www.cloudninegifts.com
   http://www.meanstreamradio.com   http://www.unknown-artists.com
==




---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] Open 7.3 items

2002-08-15 Thread Tom Lane


Vince Vielhaber [EMAIL PROTECTED] writes:
 But it doesn't need to affect anyone, even if it's enabled.  Isn't
 the lack of an @ just as good as an @ at the end of the username?

No, because there isn't any @ in the incoming connection request in the
normal-user case: just a user name and a database name, which *we* have
to assemble into user@database.

We can't really expect the users to do this for us (give user@database
as their full user name).  There are a number of reasons why I don't
wanna do that, but the real showstopper is that the username field of
the connection request packet is only 32 bytes wide, and we cannot
enlarge it without a protocol breakage.  Fitting user@database in 32
bytes would be awfully restrictive about your user and database names.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Companies involved in development

2002-08-15 Thread Andrew Sullivan


I think I spelled -advocacy correctly this time.

On Thu, Aug 15, 2002 at 05:34:13PM +0200, Hans-J?rgen Sch?nig wrote:
 I think it would be a huge benefit for the community to have some more 
 company-funding. This would lead to the implementation of some features 
 people need urgently (replication in the core and so forth). On the 

 For a company PostgreSQL definitely is an interesting area to invest 
 because it has proven to be a good product and there are just minor 
 things (sync. replication - eg. Postgres-R) missing to make it a real 
 enterprise database. The support of the community of more than just 
 optimal and it is an interesting subject.

 Also: It would be interesting to have a special section on the website 
 where people can post that they need money to implement something really 
 useful. I guess there'd be a lot of people who'd pay for replication or 
 things like that if they knew more.

Some time ago, I posted that I was looking for people interested in
making the replication stuff complete.  I'm still working on that
(and I _may_ be getting somewhere, BTW), but there is a lot of work
to be done there, and I think quite a bit of high-quality code needs
to be written.  And that high-quiality code requires high-quality
developers.

Now, it strikes me that sometimes, several companies might be able to
afford to subsidise this sort of development, if only they had a way
of getting together to do this.  I find that the corporate folks here
really like the idea of co-development.  The idea is to spread the
risk, where everyone gets the return.  Can anyone think of an idea of
how to set up some sort of organisation to do this?  Or maybe, are
commercial organisations like PostgreSQL the best answer?  The
problem is frequently that the names of the funders frequently need
to remain secret-ish, because a lot of companies are reluctant to
discuss using Postgres.

Any suggestions?  I know I'd have an easier sell to support this sort
of development if we didn't have to foot the whole bill.

A

-- 

Andrew Sullivan   87 Mowat Avenue 
Liberty RMS   Toronto, Ontario Canada
[EMAIL PROTECTED]  M6K 3E3
 +1 416 646 3304 x110


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] Open 7.3 items

2002-08-15 Thread Bruce Momjian


Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
  + /* We append database name if db_user_namespace true. */
  + #define SM_DATABASE_USER (SM_DATABASE+SM_USER)
 
 Is this calculation correct?  I'd think you'd need at least one more
 character to allow for the @.  And I'm not sure about whether trailing
 nulls are or need to be counted.  There seem to be some places in your
 patch where things are dimensioned SM_DATABASE_USER and some where it's
 SM_DATABASE_USER+1; why the inconsistency, and which is right?

Yes, there was some inconsistency.  The new patch fixes that up; 
attached.

 Other than getting the array sizes right, it does look like a nice
 patch; very small, which is what I'd hoped for.  The notion of having to
 say postgres@ still seems kinda ugly, but given the simplicity of the
 patch I'm willing to live with that.

Glad we have something now everyone likes, or at least can live with.

-- 
  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


Index: doc/src/sgml/runtime.sgml
===
RCS file: /cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.125
diff -c -r1.125 runtime.sgml
*** doc/src/sgml/runtime.sgml   15 Aug 2002 14:26:15 -  1.125
--- doc/src/sgml/runtime.sgml   15 Aug 2002 16:34:12 -
***
*** 1191,1196 
--- 1191,1211 
   /varlistentry
  
   varlistentry
+   termvarnameDB_USER_NAMESPACE/varname (typeboolean/type)/term
+   listitem
+para
+ Appends literal@/ and the database name to the user name when
+ connecting to the database.  This allows per-database users.  
+ User names ending with literal@/ are considered global and may 
+ connect to any database.  It is recommended you create at least one 
+ global user, e.g. literalpostgres@/, before enabling this feature.  
+ Also, when creating user names containing literal@/, you will need 
+ to quote the user name.
+/para
+   /listitem
+  /varlistentry
+ 
+  varlistentry
indexterm
 primarydeadlock/primary
 secondarytimeout/secondary
Index: src/backend/libpq/auth.c
===
RCS file: /cvsroot/pgsql-server/src/backend/libpq/auth.c,v
retrieving revision 1.82
diff -c -r1.82 auth.c
*** src/backend/libpq/auth.c20 Jun 2002 20:29:28 -  1.82
--- src/backend/libpq/auth.c15 Aug 2002 16:34:13 -
***
*** 117,123 
 version, PG_KRB4_VERSION);
return STATUS_ERROR;
}
!   if (strncmp(port-user, auth_data.pname, SM_USER) != 0)
{
elog(LOG, pg_krb4_recvauth: name \%s\ != \%s\,
 port-user, auth_data.pname);
--- 117,123 
 version, PG_KRB4_VERSION);
return STATUS_ERROR;
}
!   if (strncmp(port-user, auth_data.pname, SM_DATABASE_USER) != 0)
{
elog(LOG, pg_krb4_recvauth: name \%s\ != \%s\,
 port-user, auth_data.pname);
***
*** 290,296 
}
  
kusername = pg_an_to_ln(kusername);
!   if (strncmp(port-user, kusername, SM_USER))
{
elog(LOG, pg_krb5_recvauth: user name \%s\ != krb5 name \%s\,
 port-user, kusername);
--- 290,296 
}
  
kusername = pg_an_to_ln(kusername);
!   if (strncmp(port-user, kusername, SM_DATABASE_USER))
{
elog(LOG, pg_krb5_recvauth: user name \%s\ != krb5 name \%s\,
 port-user, kusername);
Index: src/backend/postmaster/postmaster.c
===
RCS file: /cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v
retrieving revision 1.283
diff -c -r1.283 postmaster.c
*** src/backend/postmaster/postmaster.c 10 Aug 2002 20:29:18 -  1.283
--- src/backend/postmaster/postmaster.c 15 Aug 2002 16:34:15 -
***
*** 116,122 
  sigset_t  UnBlockSig,
BlockSig,
AuthBlockSig;
- 
  #else
  int   UnBlockSig,
BlockSig,
--- 116,121 
***
*** 191,196 
--- 190,197 
  bool  HostnameLookup; /* for ps display */
  bool  ShowPortNumber;
  bool  Log_connections = false;
+ bool  Db_user_namespace = false;
+ 
  
  /* Startup/shutdown state */
  static pid_t StartupPID = 0,
***
*** 1161,1166 
--- 1162,1177 
if (port-user[0] == '\0')
elog(FATAL, no PostgreSQL user name specified in startup packet);
  
+   /* Append

Re: [HACKERS] failure notice (fwd)

2002-08-15 Thread Bruce Momjian



Yep, I just sent email to Marc to remove them.

---

Vince Vielhaber wrote:
 
 Who the hell are these people and why can't they configure their
 own MTA?
 
 Vince.
 -- 
 ==
 Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
  56K Nationwide Dialup from $16.00/mo at Pop4 Networking
   http://www.camping-usa.com  http://www.cloudninegifts.com
http://www.meanstreamradio.com   http://www.unknown-artists.com
 ==
 
 
 
 -- Forwarded message --
 Date: 15 Aug 2002 16:47:22 -
 From: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: failure notice
 
 Hi. This is the qmail-send program at ic.kharkov.ua.
 I'm afraid I wasn't able to deliver your message to the following addresses.
 This is a permanent error; I've given up. Sorry it didn't work out.
 
 [EMAIL PROTECTED]:
 Connected to 192.204.191.242 but sender was rejected.
 Remote host said: 550 5.0.0 Go away, your mailserver is broken
 
 --- Below this line is a copy of the message.
 
 Return-Path: [EMAIL PROTECTED]
 Received: (qmail 62268 invoked from network); 15 Aug 2002 16:46:47 -
 Received: from dialup44.kharkov.ukrpack.net (HELO dual.shena.ic.kharkov.ua) 
(212.1.112.156)
   by mail.ic.kharkov.ua with SMTP; 15 Aug 2002 16:46:47 -
 Received: from dual.shena.ic.kharkov.ua (DUAL [172.16.200.1]) by 
dual.shena.ic.kharkov.ua with SMTP (Microsoft Exchange Internet Mail Service Version 
5.5.2448.0)
   id Q926YA3A; Thu, 15 Aug 2002 19:46:07 +0300
 Received: by dual.shena.ic.kharkov.ua (Microsoft Exchange Connector for POP3 
Mailboxes 4.50.2113) with SMTP (Global POP3 Download)
id [EMAIL PROTECTED]; Thu, 15 Aug 2002 19:45:56 
+0300
 Return-Path: [EMAIL PROTECTED]
 Delivered-To: [EMAIL PROTECTED]
 Received: (qmail 61671 invoked by alias); 15 Aug 2002 16:39:03 -
 Delivered-To: [EMAIL PROTECTED]
 Received: (qmail 61668 invoked from network); 15 Aug 2002 16:39:03 -
 Received: from postgresql.org (64.49.215.8)
   by mail.ic.kharkov.ua with SMTP; 15 Aug 2002 16:39:03 -
 Received: from localhost (postgresql.org [64.49.215.8])
   by postgresql.org (Postfix) with ESMTP
   id 419EF47654E; Thu, 15 Aug 2002 12:38:48 -0400 (EDT)
 Received: from postgresql.org (postgresql.org [64.49.215.8])
   by postgresql.org (Postfix) with SMTP
   id A2668475F2D; Thu, 15 Aug 2002 12:38:47 -0400 (EDT)
 Received: from localhost (postgresql.org [64.49.215.8])
   by postgresql.org (Postfix) with ESMTP id EE137475974
   for [EMAIL PROTECTED]; Thu, 15 Aug 2002 12:38:44 -0400 (EDT)
 Received: from paprika.michvhf.com (adsl-67-36-71-182.dsl.sfldmi.ameritech.net 
[67.36.71.182])
   by postgresql.org (Postfix) with SMTP id DCB8947594D
   for [EMAIL PROTECTED]; Thu, 15 Aug 2002 12:38:43 -0400 (EDT)
 Received: (qmail 55151 invoked by uid 1001); 15 Aug 2002 16:38:45 -
 Date: Thu, 15 Aug 2002 12:38:45 -0400 (EDT)
 From: Vince Vielhaber [EMAIL PROTECTED]
 To: Bruce Momjian [EMAIL PROTECTED]
 Cc: Tom Lane [EMAIL PROTECTED], Lamar Owen [EMAIL PROTECTED],
   PostgreSQL-development [EMAIL PROTECTED]
 Subject: Re: [HACKERS] Open 7.3 items
 In-Reply-To: [EMAIL PROTECTED]
 Message-ID: [EMAIL PROTECTED]
 MIME-Version: 1.0
 Content-Type: TEXT/PLAIN; charset=US-ASCII
 X-Virus-Scanned: by AMaViS new-20020517
 Precedence: bulk
 Sender: [EMAIL PROTECTED]
 X-Virus-Scanned: by AMaViS new-20020517
 
 On Thu, 15 Aug 2002, Bruce Momjian wrote:
 
  Vince Vielhaber wrote:
   On Thu, 15 Aug 2002, Bruce Momjian wrote:
  
   
OK, no one complained/commented on my idea of having global users have a
trailing '@', so here is a patch that implements that.  It has the
advantages of:
  
   Probably because not everyone saw it.  I know I didn't.  This entire
   issue is growing more and more complex.  How about a configure item
   to not even compile it in?  Or better yet, a configure item to put
   it there with the default off.
 
  I think I am prety close, and I don't see a configure flag as any better
  than a GUC option that is off by default.
 
 But how many people would even use it?  I can't see adding the bloat
 unnecessarily and risking it accidently being turned on.  Am I wrong
 and really alot of people actually want/need this?
 
 Vince.
 -- 
 ==
 Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
  56K Nationwide Dialup from $16.00/mo at Pop4 Networking
   http://www.camping-usa.com  http://www.cloudninegifts.com
http://www.meanstreamradio.com   http://www.unknown-artists.com
 ==
 
 
 
 
 ---(end of broadcast)---
 TIP 6:

Re: [HACKERS] failure notice (fwd)

2002-08-15 Thread Tom Lane


Vince Vielhaber [EMAIL PROTECTED] writes:
 Who the hell are these people and why can't they configure their
 own MTA?

 Hi. This is the qmail-send program at ic.kharkov.ua.
 I'm afraid I wasn't able to deliver your message to the following addresses.
 This is a permanent error; I've given up. Sorry it didn't work out.

 [EMAIL PROTECTED]:
 Connected to 192.204.191.242 but sender was rejected.
 Remote host said: 550 5.0.0 Go away, your mailserver is broken

Oh my.  I started blocking them about two hours ago after the first
dozen or so duplicate copies of messages came through here.  It didn't
occur to me that I might be making the problem worse for other victims :-(.
Sorry about that.

Marc, would you please kill whoever-it-is-at-kharkov.ua from the mailing
lists, pronto?

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] Standard replication interface?

2002-08-15 Thread Greg Copeland


On Thu, 2002-08-15 at 09:53, Neil Conway wrote:
 That's exactly what I was going to say -- I'd prefer that any
 interested parties concentrate on producing a *really good*
 replication implementation, which might eventually be integrated into
 PostgreSQL itself.
 
 Producing a generic API for something that really doesn't need
 genericity sounds like a waste of time, IMHO.
 
 Cheers,
 
 Neil


Some how I get the impression that I've been completely misunderstood. 
Somehow, people seem to of only read the subject and skipped the body
explaining the concept.

In what way would providing a generic interface to *monitor* be a waste
of time?  In what way would that prevent someone from producing a
*readlly good* replication implementation?  I utterly fail to see the
connection.

Regards,
Greg Copeland




signature.asc
Description: This is a digitally signed message part

Re: [HACKERS] Companies involved in development

2002-08-15 Thread Bruce Momjian



I am willing to talk to anyone about this.  There is a reason my phone
number is in my signature (note new phone number;  I just moved.)

Also, I am willing to make trips to companies to talk about PostgreSQL.
I can't make 100's of trips a year, but I try to do at least on a month.
I just did one last week. If your company is interested in funding or a
visit to talk about PostgreSQL, I am ready.  Also, for the advocacy
site, I will be putting together a list of people around the world who
are ready to talk via phone or visit about PostgreSQL.

I am a little bogged down on the pre-beta issue, but plan to hit this
full force once beta begins.

---

Andrew Sullivan wrote:
 I think I spelled -advocacy correctly this time.
 
 On Thu, Aug 15, 2002 at 05:34:13PM +0200, Hans-J?rgen Sch?nig wrote:
  I think it would be a huge benefit for the community to have some more 
  company-funding. This would lead to the implementation of some features 
  people need urgently (replication in the core and so forth). On the 
 
  For a company PostgreSQL definitely is an interesting area to invest 
  because it has proven to be a good product and there are just minor 
  things (sync. replication - eg. Postgres-R) missing to make it a real 
  enterprise database. The support of the community of more than just 
  optimal and it is an interesting subject.
 
  Also: It would be interesting to have a special section on the website 
  where people can post that they need money to implement something really 
  useful. I guess there'd be a lot of people who'd pay for replication or 
  things like that if they knew more.
 
 Some time ago, I posted that I was looking for people interested in
 making the replication stuff complete.  I'm still working on that
 (and I _may_ be getting somewhere, BTW), but there is a lot of work
 to be done there, and I think quite a bit of high-quality code needs
 to be written.  And that high-quiality code requires high-quality
 developers.
 
 Now, it strikes me that sometimes, several companies might be able to
 afford to subsidise this sort of development, if only they had a way
 of getting together to do this.  I find that the corporate folks here
 really like the idea of co-development.  The idea is to spread the
 risk, where everyone gets the return.  Can anyone think of an idea of
 how to set up some sort of organisation to do this?  Or maybe, are
 commercial organisations like PostgreSQL the best answer?  The
 problem is frequently that the names of the funders frequently need
 to remain secret-ish, because a lot of companies are reluctant to
 discuss using Postgres.
 
 Any suggestions?  I know I'd have an easier sell to support this sort
 of development if we didn't have to foot the whole bill.
 
 A
 
 -- 
 
 Andrew Sullivan   87 Mowat Avenue 
 Liberty RMS   Toronto, Ontario Canada
 [EMAIL PROTECTED]  M6K 3E3
  +1 416 646 3304 x110
 
 
 ---(end of broadcast)---
 TIP 5: Have you checked our extensive FAQ?
 
 http://www.postgresql.org/users-lounge/docs/faq.html
 

-- 
  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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Companies involved in development

2002-08-15 Thread Bruce Momjian



Of course, any funding information would be shared by the core group so
they are involved, but not shared to the general list until the company
wishes.


---

Andrew Sullivan wrote:
 I think I spelled -advocacy correctly this time.
 
 On Thu, Aug 15, 2002 at 05:34:13PM +0200, Hans-J?rgen Sch?nig wrote:
  I think it would be a huge benefit for the community to have some more 
  company-funding. This would lead to the implementation of some features 
  people need urgently (replication in the core and so forth). On the 
 
  For a company PostgreSQL definitely is an interesting area to invest 
  because it has proven to be a good product and there are just minor 
  things (sync. replication - eg. Postgres-R) missing to make it a real 
  enterprise database. The support of the community of more than just 
  optimal and it is an interesting subject.
 
  Also: It would be interesting to have a special section on the website 
  where people can post that they need money to implement something really 
  useful. I guess there'd be a lot of people who'd pay for replication or 
  things like that if they knew more.
 
 Some time ago, I posted that I was looking for people interested in
 making the replication stuff complete.  I'm still working on that
 (and I _may_ be getting somewhere, BTW), but there is a lot of work
 to be done there, and I think quite a bit of high-quality code needs
 to be written.  And that high-quiality code requires high-quality
 developers.
 
 Now, it strikes me that sometimes, several companies might be able to
 afford to subsidise this sort of development, if only they had a way
 of getting together to do this.  I find that the corporate folks here
 really like the idea of co-development.  The idea is to spread the
 risk, where everyone gets the return.  Can anyone think of an idea of
 how to set up some sort of organisation to do this?  Or maybe, are
 commercial organisations like PostgreSQL the best answer?  The
 problem is frequently that the names of the funders frequently need
 to remain secret-ish, because a lot of companies are reluctant to
 discuss using Postgres.
 
 Any suggestions?  I know I'd have an easier sell to support this sort
 of development if we didn't have to foot the whole bill.
 
 A
 
 -- 
 
 Andrew Sullivan   87 Mowat Avenue 
 Liberty RMS   Toronto, Ontario Canada
 [EMAIL PROTECTED]  M6K 3E3
  +1 416 646 3304 x110
 
 
 ---(end of broadcast)---
 TIP 5: Have you checked our extensive FAQ?
 
 http://www.postgresql.org/users-lounge/docs/faq.html
 

-- 
  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 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] failure notice (fwd)

2002-08-15 Thread Marc G. Fournier



all gone ...

On Thu, 15 Aug 2002, Vince Vielhaber wrote:


 Who the hell are these people and why can't they configure their
 own MTA?

 Vince.
 --
 ==
 Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
  56K Nationwide Dialup from $16.00/mo at Pop4 Networking
   http://www.camping-usa.com  http://www.cloudninegifts.com
http://www.meanstreamradio.com   http://www.unknown-artists.com
 ==



 -- Forwarded message --
 Date: 15 Aug 2002 16:47:22 -
 From: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: failure notice

 Hi. This is the qmail-send program at ic.kharkov.ua.
 I'm afraid I wasn't able to deliver your message to the following addresses.
 This is a permanent error; I've given up. Sorry it didn't work out.

 [EMAIL PROTECTED]:
 Connected to 192.204.191.242 but sender was rejected.
 Remote host said: 550 5.0.0 Go away, your mailserver is broken

 --- Below this line is a copy of the message.

 Return-Path: [EMAIL PROTECTED]
 Received: (qmail 62268 invoked from network); 15 Aug 2002 16:46:47 -
 Received: from dialup44.kharkov.ukrpack.net (HELO dual.shena.ic.kharkov.ua) 
(212.1.112.156)
   by mail.ic.kharkov.ua with SMTP; 15 Aug 2002 16:46:47 -
 Received: from dual.shena.ic.kharkov.ua (DUAL [172.16.200.1]) by 
dual.shena.ic.kharkov.ua with SMTP (Microsoft Exchange Internet Mail Service Version 
5.5.2448.0)
   id Q926YA3A; Thu, 15 Aug 2002 19:46:07 +0300
 Received: by dual.shena.ic.kharkov.ua (Microsoft Exchange Connector for POP3 
Mailboxes 4.50.2113) with SMTP (Global POP3 Download)
id [EMAIL PROTECTED]; Thu, 15 Aug 2002 19:45:56 
+0300
 Return-Path: [EMAIL PROTECTED]
 Delivered-To: [EMAIL PROTECTED]
 Received: (qmail 61671 invoked by alias); 15 Aug 2002 16:39:03 -
 Delivered-To: [EMAIL PROTECTED]
 Received: (qmail 61668 invoked from network); 15 Aug 2002 16:39:03 -
 Received: from postgresql.org (64.49.215.8)
   by mail.ic.kharkov.ua with SMTP; 15 Aug 2002 16:39:03 -
 Received: from localhost (postgresql.org [64.49.215.8])
   by postgresql.org (Postfix) with ESMTP
   id 419EF47654E; Thu, 15 Aug 2002 12:38:48 -0400 (EDT)
 Received: from postgresql.org (postgresql.org [64.49.215.8])
   by postgresql.org (Postfix) with SMTP
   id A2668475F2D; Thu, 15 Aug 2002 12:38:47 -0400 (EDT)
 Received: from localhost (postgresql.org [64.49.215.8])
   by postgresql.org (Postfix) with ESMTP id EE137475974
   for [EMAIL PROTECTED]; Thu, 15 Aug 2002 12:38:44 -0400 (EDT)
 Received: from paprika.michvhf.com (adsl-67-36-71-182.dsl.sfldmi.ameritech.net 
[67.36.71.182])
   by postgresql.org (Postfix) with SMTP id DCB8947594D
   for [EMAIL PROTECTED]; Thu, 15 Aug 2002 12:38:43 -0400 (EDT)
 Received: (qmail 55151 invoked by uid 1001); 15 Aug 2002 16:38:45 -
 Date: Thu, 15 Aug 2002 12:38:45 -0400 (EDT)
 From: Vince Vielhaber [EMAIL PROTECTED]
 To: Bruce Momjian [EMAIL PROTECTED]
 Cc: Tom Lane [EMAIL PROTECTED], Lamar Owen [EMAIL PROTECTED],
   PostgreSQL-development [EMAIL PROTECTED]
 Subject: Re: [HACKERS] Open 7.3 items
 In-Reply-To: [EMAIL PROTECTED]
 Message-ID: [EMAIL PROTECTED]
 MIME-Version: 1.0
 Content-Type: TEXT/PLAIN; charset=US-ASCII
 X-Virus-Scanned: by AMaViS new-20020517
 Precedence: bulk
 Sender: [EMAIL PROTECTED]
 X-Virus-Scanned: by AMaViS new-20020517

 On Thu, 15 Aug 2002, Bruce Momjian wrote:

  Vince Vielhaber wrote:
   On Thu, 15 Aug 2002, Bruce Momjian wrote:
  
   
OK, no one complained/commented on my idea of having global users have a
trailing '@', so here is a patch that implements that.  It has the
advantages of:
  
   Probably because not everyone saw it.  I know I didn't.  This entire
   issue is growing more and more complex.  How about a configure item
   to not even compile it in?  Or better yet, a configure item to put
   it there with the default off.
 
  I think I am prety close, and I don't see a configure flag as any better
  than a GUC option that is off by default.

 But how many people would even use it?  I can't see adding the bloat
 unnecessarily and risking it accidently being turned on.  Am I wrong
 and really alot of people actually want/need this?

 Vince.
 --
 ==
 Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
  56K Nationwide Dialup from $16.00/mo at Pop4 Networking
   http://www.camping-usa.com  http://www.cloudninegifts.com
http://www.meanstreamradio.com   http://www.unknown-artists.com
 ==




 ---(end of broadcast)---
 TIP 6: Have you searched our list archives?

 http://archives.postgresql.org



 ---(end of

Re: [HACKERS] Standard replication interface?

2002-08-15 Thread Greg Copeland


 As I said -- I don't really see the need for a bunch of replication
 implementations, and therefore I don't see the need for a generic API
 to make the whole mess (slightly) more manageable.

I see.  So the intension of the core developers is to have one and only
one replication solution?

Greg






signature.asc
Description: This is a digitally signed message part

Re: [HACKERS] Open 7.3 items

2002-08-15 Thread Rod Taylor



 But how many people would even use it?  I can't see adding the bloat
 unnecessarily and risking it accidently being turned on.  Am I wrong
 and really alot of people actually want/need this?

At an absolute minimum there are two.  Myself and Marc.

That said, this is a semi-required step to offerring Postgresql as a
service to clients.  The refined permissions where a much more important
step.

So, take the number of people actively watching -hackers and use that as
a percentage.




---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] Standard replication interface?

2002-08-15 Thread Neil Conway


Greg Copeland [EMAIL PROTECTED] writes:
  As I said -- I don't really see the need for a bunch of replication
  implementations, and therefore I don't see the need for a generic API
  to make the whole mess (slightly) more manageable.
 
 I see.  So the intension of the core developers is to have one and only
 one replication solution?

Not being a core developer, I can't comment on their intentions.

That said, I _personally_ don't see the need for more than one or two
replication implementations. You might need more than one if you
wanted to do both lazy and eager replication, for example. But you
certainly don't need 5 or 6 or however many implementations exist at
the moment.

I think the reason there are a lot of different implementations at the
moment is that each one has some pretty serious problems. So rather
than trying to reduce the problem by making it slightly easier for the
different replication solutions to inter-operate, I think it's a
better idea to solve the problem outright by improving one of the
existing replication projects to the point at which it is ready for
widespread production usage.

Cheers,

Neil

-- 
Neil Conway [EMAIL PROTECTED]
PGP Key ID: DB3C29FC


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

[HACKERS] unsubscribe

2002-08-15 Thread J.J. Karels




unsubscribe

[HACKERS] Admin nice-to-have's

2002-08-15 Thread Scott Shattuck


A couple of admin nice-to-have's based on the last few weeks of 24x7
operation are:

Allow DBA/Database Owner to log in even when max_connections has been
reached so they can determine which queries are hung via
pg_stat_activity etc. and perform any other needed work to restore
stability.

Log offending query during DEBUG logging for syntax errors, missing
tables/attributes, etc. so that the offending queries can be located in
the codebase.



ss





---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Standard replication interface?

2002-08-15 Thread Greg Copeland


On Thu, 2002-08-15 at 13:18, Neil Conway wrote:
 That said, I _personally_ don't see the need for more than one or two
 replication implementations. You might need more than one if you
 wanted to do both lazy and eager replication, for example. But you
 certainly don't need 5 or 6 or however many implementations exist at
 the moment.

Fair enough.  Thank you for offering a complete explanation.

You're argument certainly made sense.  I wasn't aware of any single
serious effort underway which sought to finally put replication to bed,
let alone integrated into the core code base.

Sign,

Greg Copeland



signature.asc
Description: This is a digitally signed message part

Re: [HACKERS] pg_dump output portability

2002-08-15 Thread Peter Eisentraut


Tom Lane writes:

 Ah.  But where exactly will you substitute true for 't'?  I don't think
 pg_dump necessarily knows enough to apply that transformation.

Sure, it does it already for other types.  Look for BITOID in pg_dump.c.

 Switching the default is definitely fine with me, but I'd lean towards
 ripping it out entirely, given that the backend-supplied chunks of stuff
 are not going to have extra quotes.  We always tell people always quote
 or never quote a given identifier; pg_dump scripts ought to follow that
 rule.

It occurred to me that pg_dump would need to know which names are
keywords.  Ugh.

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Standard replication interface?

2002-08-15 Thread cbbrowne


 --=-QQHYShMlxI2BY71i6NiO
 Content-Type: text/plain
 Content-Transfer-Encoding: quoted-printable
 
  As I said -- I don't really see the need for a bunch of replication
  implementations, and therefore I don't see the need for a generic API
  to make the whole mess (slightly) more manageable.
 
 I see.  So the intension of the core developers is to have one and only
 one replication solution?

If the various solutions may be folded down into a smaller set of programs, 
perhaps, ultimately, into _one_ program, that would surely be easier to 
manage, in the codebase, than having five or six such programs.

If one program can do the job that needs to be done, and it has not been 
_clearly_ established that that is _not_ possible, then I'd think it rather 
silly to have a bunch of replication solutions that need to be updated any 
time a relevant change goes into the database engine.

I'd be surprised if, in the end, there truly _needed_ to be more than about 
two approaches.

Should the team plan to _have_ a mess?  I'd think not.
--
(concatenate 'string cbbrowne ntlug.org)
http://cbbrowne.com/info/linuxdistributions.html
We don't understand the  software, and sometimes we don't  understand
the hardware, but we can *see* the blinking lights!  -- Unknown



---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] pg_dump large file support

2002-08-15 Thread Peter Eisentraut


Oliver Elphick writes:

 I've implemented large file support for pg_dump, in what I hope is a
 portable fashion.  Please review the attached patch.

Hmm, not quite right, but since you've indicated that you're not familiar
with Autoconf I can take it from here.

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] Open 7.3 issues

2002-08-15 Thread Peter Eisentraut


Bruce Momjian writes:

   Socket permissions - only install user can access db by default
   unix_socket_permissions in postgresql.conf

This is dead.

   glibc and mktime() - fix?

Leave it be.  If someone really needs time information from before 1970
(and who does?) he wouldn't use an OS that doesn't support it anyway.
There are several platforms that don't have complete time information
before 1947 and we've lived with those, too.

   ecpg and bison issues - solved?

A release is cooking.  1.49b was released just a few days ago.  Assuming
that it is sane and no final release comes out before beta, we might ship
our beta built with their beta and coordinate with them to make a final
release during our beta.  It's a bit risky, but the more testing we can
provide to them the faster they will get a release out.

   fix BeOS and QNX4 ports

 Should we ship 7.3 without these ports?

Porters usually appear during beta.

   integrate or remove new libpqxx
   integrate or add to gborg Pg:DBD

 Seems like gborg is the place for these.

I would volunteer to package libpq++ separately.

   move pg_resetxlog and pg_controldata to main tree, add -f flag

 That is me. I  will get to it.

What does -f do?

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Documentation DTD

2002-08-15 Thread Peter Eisentraut


Rod Taylor writes:

 Anyone mind if we bump the DTD version to Docbook 4.2?

Not sure if we should do this now.  We're approaching the time where
people should be writing documentation, not having to refiddle their
carefully crafted DocBook installations.  We're not going to realize any
immediate benefits anyway.

 What it buys is a number of useful tags, SVGs and probably more
 importantly for the future, xsl and fop support which will probably be
 important in the future.  OpenJade hasn't had a new release in quite a
 long time -- not to say work isn't needed.

The last release was in January.

 Yes, after updating docs to the newer DTD I intend to make them XML
 compliant to ensure they work with v5 of docbook in the future.

Ah, an XML vs. SGML debate.  I look forward to it.

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Documentation DTD

2002-08-15 Thread Rod Taylor



  Yes, after updating docs to the newer DTD I intend to make them XML
  compliant to ensure they work with v5 of docbook in the future.
 
 Ah, an XML vs. SGML debate.  I look forward to it.

This one is pretty simple.  It's been announced that the docbook group
isn't looking to continue with SGML.  This is shown on the oasis-open
pages as well as their discussion in the mailing lists (xsltproc and fop
rather than jade and dsssl).

I prefer working with SGML, but not enough to try hacking away at
openjade to finish it off :)


Anyway, you're right about the patch.  Lets apply it to the 7.4 tree 
after branching.


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] pg_dump large file support

2002-08-15 Thread Oliver Elphick


On Thu, 2002-08-15 at 20:30, Peter Eisentraut wrote:
 Oliver Elphick writes:
 
  I've implemented large file support for pg_dump, in what I hope is a
  portable fashion.  Please review the attached patch.
 
 Hmm, not quite right, but since you've indicated that you're not familiar
 with Autoconf I can take it from here.

Thanks, Peter
-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight, UK
http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 Praying always with all prayer and supplication in the
  Spirit, and watching thereunto with all perseverance 
  and supplication for all saints.   Ephesians 6:18


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Open 7.3 items

2002-08-15 Thread Tom Lane


Peter Eisentraut [EMAIL PROTECTED] writes:
 I don't see what the problem is of dumping out the entire content of
 pg_shadow into a flat file.  First you look for a non-@ user, then you
 look for an @ user that matches the database.

While I'd prefer that approach myself, the way Bruce is proposing does
have a definite advantage: there is no problem with confusion between
global users and database-local users of the same username.  foo@ is
global, foo is not.

My own feeling is that the confusion argument is a weak one, and that
not having to use @ to log in as a global user would be worth having
to avoid duplicating global and local names.  But I'm not sufficiently
excited about it to volunteer to do the work ;-)

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] Open 7.3 items

2002-08-15 Thread Vince Vielhaber


On Thu, 15 Aug 2002, Tom Lane wrote:

 Peter Eisentraut [EMAIL PROTECTED] writes:
  I don't see what the problem is of dumping out the entire content of
  pg_shadow into a flat file.  First you look for a non-@ user, then you
  look for an @ user that matches the database.

 While I'd prefer that approach myself, the way Bruce is proposing does
 have a definite advantage: there is no problem with confusion between
 global users and database-local users of the same username.  foo@ is
 global, foo is not.

 My own feeling is that the confusion argument is a weak one, and that
 not having to use @ to log in as a global user would be worth having
 to avoid duplicating global and local names.  But I'm not sufficiently
 excited about it to volunteer to do the work ;-)

Here we go again.  I thought you just said that the @ wouldn't be
something a user would have to do.  I understood that to be any user.
It's back to ugly again.

Vince.
-- 
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
 56K Nationwide Dialup from $16.00/mo at Pop4 Networking
  http://www.camping-usa.com  http://www.cloudninegifts.com
   http://www.meanstreamradio.com   http://www.unknown-artists.com
==




---(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] Standard replication interface?

2002-08-15 Thread Tom Lane


Neil Conway [EMAIL PROTECTED] writes:
 Greg Copeland [EMAIL PROTECTED] writes:
 I see.  So the intension of the core developers is to have one and only
 one replication solution?

 Not being a core developer, I can't comment on their intentions.

Well, I am, but I'm only speaking for myself here:

I think there's definitely a need for at least two replication
implementations: sync and async.  The space of requirements is wide
enough that there's not a one-size-fits-all solution.  You might care
to look at Darren Johnson's OSCON slides for more about this:
http://conferences.oreillynet.com/cs/os2002/view/e_sess/3280
I think there is room for several replication solutions for Postgres
(three or four, maybe).

It's difficult to say what will wind up in our core distribution.
A tightly linked implementation like Postgres-R is really impractical
as an add-on: you need enough mods of the core code that it'd be a
nightmare to try to maintain if it's not integrated into the regular
CVS tree.  So assuming that the Postgres-R project gets to the point
of usefulness, I'd vote in favor of integrating it.  On the other hand,
it's possible to do good stuff without touching the core code at all
(cf. PostgreSQL Inc's rserv) and in that case there may or may not be
any interest in integrating the code.  It's really gonna depend mostly
on the wishes of the people who develop the replication solutions,
I think.

I can foresee a time when there are one or two replication solutions
that are included in the base distribution and others are available
separately.  In fact, counting contrib/rserv that more or less describes
the state of affairs today.  What we need is more work on the available
solutions to improve their quality and general usefulness.

As for the point at hand: I'm fairly dubious that a common monitoring
API will be very useful, considering how different the possible
replication approaches are.  If Greg can prove me wrong, fine.  But
I don't want to see us artificially constraining replication solutions
by insisting that they meet some prespecified API.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] tsearch bug in 7.2.1?

2002-08-15 Thread Ross J. Reedstrom


On Thu, Aug 15, 2002 at 11:59:20AM +0300, Oleg Bartunov wrote:
 tsearch has compiled-in stop-list, it's currently just not flexible
 as OpenFTS does. We plan to move most functionality to tsearch but
 currently have no time. Feel free to join us to speedup tsearch
 development.

Oleg - 
I think Chris's issue might be the same one I ran into just last night.
(BTW, thanks for tsearch and the OpenFTS work, it's really great)
My problem is that queries with only stopwords throw an ERROR, rather
than a WARNING or NOTICE. This means We've got to deal with catching an
exception so our middleware doesn't spew ugly errors and tracebacks at 
our endusers, and I've got to deal with cleaning up the transaction.

Having the behavior be issue a notice and return no match would give
us a reasonably functional interface: if I don't implement reading the
NOTICE, I get confused users ('huh? the doesn't match anything?')
rather than irate users ('Your search interface sucks! It keeps
crashing!')

Oh, well, off to implement some try: catch: logic.

Ross

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Companies involved in development

2002-08-15 Thread Ross J. Reedstrom


On Thu, Aug 15, 2002 at 11:05:07AM -0400, Bruce Momjian wrote:
 I think we are going to see more company-funded developers working on
 PostgreSQL.  There are a handful now, but I can see lots more coming.
 I am going to work on getting those funding companies more visibility. 
 We originally were concerned that such involvement may harm the
 development process, but history has shown that it has only been a huge
 benefit for the community.

I agree, and it's also true that while the visibility of all you
paid-to-hack types is high, the fact that you _are_ paid, and by wha
companies, is not.

Just recently, one of the GnuE developers has been running on about SapDB,
and mentioned how they've got '100 paid developers at SAP' and seemed to
think that since GreatBridge died, pgsql is back to all volunteer. The
fact that GB wasn't the first nor the only nor the last corp. funding
pgsql development was clearly missed, even among a relatively PG savvy
user community (GnuE is the GNU/Enterprise middleware system, and is is
pgsql as its primary developement backend http://www.gnuenterprise.org/ )

Ross

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Documentation DTD

2002-08-15 Thread cbbrowne


 Rod Taylor writes:
 
  Anyone mind if we bump the DTD version to Docbook 4.2?
 
 Not sure if we should do this now.  We're approaching the time where
 people should be writing documentation, not having to refiddle their
 carefully crafted DocBook installations.  We're not going to realize any
 immediate benefits anyway.

Indeed.

  What it buys is a number of useful tags, SVGs and probably more
  importantly for the future, xsl and fop support which will probably be
  important in the future.  OpenJade hasn't had a new release in quite a
  long time -- not to say work isn't needed.
 
 The last release was in January.
 
  Yes, after updating docs to the newer DTD I intend to make them XML
  compliant to ensure they work with v5 of docbook in the future.
 
 Ah, an XML vs. SGML debate.  I look forward to it.

Please no!

If and when it becomes forcibly preferable to use XML, there's a
tool called sgml2xml that is part of the sp package (which includes nsgmls 
and sgmlnorm) that does a Perfectly Good Job of this.  Totally automated.

Possible exception: sgml2xml capitalizes all the tags, and it looks like the 
XML DTD wants MixedCaseTagging, which is a rather irritating thing about XML; 
in any case, that's something that should be fixed up in one fell swoop in a 
normalize it all and make it into XML process LATER.

It would make sense to fix use of any deprecated elements, but fixing any 
XML aspects of it now is pretty much a senseless exercise.
--
(reverse (concatenate 'string moc.enworbbc enworbbc))
http://www.ntlug.org/~cbbrowne/emacs.html
Computers in the future may weigh no more than 1.5 tons.  -- POPULAR
MECHANICS magazine forecasting the relentless march of science 1955



---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Companies involved in development

2002-08-15 Thread Robert Treat


On Thu, 2002-08-15 at 17:13, Ross J. Reedstrom wrote:
 On Thu, Aug 15, 2002 at 11:05:07AM -0400, Bruce Momjian wrote:
  I think we are going to see more company-funded developers working on
  PostgreSQL.  There are a handful now, but I can see lots more coming.
  I am going to work on getting those funding companies more visibility. 
  We originally were concerned that such involvement may harm the
  development process, but history has shown that it has only been a huge
  benefit for the community.
 
 I agree, and it's also true that while the visibility of all you
 paid-to-hack types is high, the fact that you _are_ paid, and by wha
 companies, is not.
 

At a minimum we could have people attach a company name to their
developer bios (http://developer.postgresql.org/bios.php) if their
company pays them to hack on postgresql. (at the developers discretion
of course) At the least I would think companies like postgresql inc
would benefit from publicity that we employee X number of pg
developers.

We could also generate a list of companies sponsoring postgresql
development, but we'd have to come up with some criterion as to what it
means to be a sponsors. For example, a coworker and I were discussing a
patch he is getting ready to submit this morning while we were on the
clock. While our company doesn't have an issue with this,  I don't know
that I would say they sponsor postgresql development, they just happen
to employ two guys who are more involved than most and will hack code if
it scratches our particular itch.

Robert Treat 


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Open 7.3 items

2002-08-15 Thread Bruce Momjian


Tom Lane wrote:
 Peter Eisentraut [EMAIL PROTECTED] writes:
  I don't see what the problem is of dumping out the entire content of
  pg_shadow into a flat file.  First you look for a non-@ user, then you
  look for an @ user that matches the database.
 
 While I'd prefer that approach myself, the way Bruce is proposing does
 have a definite advantage: there is no problem with confusion between
 global users and database-local users of the same username.  foo@ is
 global, foo is not.
 
 My own feeling is that the confusion argument is a weak one, and that
 not having to use @ to log in as a global user would be worth having
 to avoid duplicating global and local names.  But I'm not sufficiently
 excited about it to volunteer to do the work ;-)

If we don't suffix global users with '@', a global user named 'dave'
could not attach to a database called 'db1' as himself if a user called
'dave@db1' existed. If you have a super-user, who you want to be able to
connect to any database, the creation of that name in any database would
block the superuser from connecting as themselves.  That is the
confusion I want to avoid.  

I have seen some negative reactions to the feature.  I am willing to ask
for a vote, if that is what people want.  If not, I will apply the patch
in the next day or two.

-- 
  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 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] Open 7.3 issues

2002-08-15 Thread Bruce Momjian


Jan Wieck wrote:
 Bruce Momjian wrote:
  
  Allow PL/PgSQL functions to return sets
  
  Is anyone working on this?  We will get beaten up if we don't have this
  for 7.3 and it is available in other languages.
 
 That's true. I think I have to do this one. I'm busy for the next 2-3
 weeks (Mom will be back from her Westcoast trip tonight and stay for
 another 3 weeks). But I should be able to do something after that.

Nope.  We are in beta then.  Either someone else will have to do it or
it will wait for 7.4.

-- 
  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] Open 7.3 items

2002-08-15 Thread Rod Taylor


 I have seen some negative reactions to the feature.  I am willing to ask
 for a vote, if that is what people want.  If not, I will apply the patch
 in the next day or two.

Please apply.


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] tsearch bug in 7.2.1?

2002-08-15 Thread Christopher Kings-Lynne


Ross - maybe we could work on a little function for tsearch - parse_query()
or something like that.  It could return true or false depending on whether
it would cause tsearch to error or not...

Chris

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Ross J.
 Reedstrom
 Sent: Friday, 16 August 2002 4:59 AM
 To: Oleg Bartunov
 Cc: Christopher Kings-Lynne; Hackers
 Subject: Re: [HACKERS] tsearch bug in 7.2.1?


 On Thu, Aug 15, 2002 at 11:59:20AM +0300, Oleg Bartunov wrote:
  tsearch has compiled-in stop-list, it's currently just not flexible
  as OpenFTS does. We plan to move most functionality to tsearch but
  currently have no time. Feel free to join us to speedup tsearch
  development.

 Oleg -
 I think Chris's issue might be the same one I ran into just last night.
 (BTW, thanks for tsearch and the OpenFTS work, it's really great)
 My problem is that queries with only stopwords throw an ERROR, rather
 than a WARNING or NOTICE. This means We've got to deal with catching an
 exception so our middleware doesn't spew ugly errors and tracebacks at
 our endusers, and I've got to deal with cleaning up the transaction.

 Having the behavior be issue a notice and return no match would give
 us a reasonably functional interface: if I don't implement reading the
 NOTICE, I get confused users ('huh? the doesn't match anything?')
 rather than irate users ('Your search interface sucks! It keeps
 crashing!')

 Oh, well, off to implement some try: catch: logic.

 Ross

 ---(end of broadcast)---
 TIP 4: Don't 'kill -9' the postmaster



---(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] Open 7.3 items

2002-08-15 Thread Tom Lane


Bruce Momjian [EMAIL PROTECTED] writes:
 If we don't suffix global users with '@', a global user named 'dave'
 could not attach to a database called 'db1' as himself if a user called
 'dave@db1' existed.

No, it's the other way around (assuming you check user before user@db):
the existence of a global user would prevent similarly-named local users
from connecting.  This does not strike me as too terrible, assuming that
there are not very many global users.

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])

[HACKERS] Bug/Change in behavior for 7.3 vs 7.2.1

2002-08-15 Thread Barry Lind


I was just testing my product running on a 7.3 snapshot from a few days 
ago.  And I ran into the following change in behavior that I consider a 
bug.  You can no long insert large values into a bigint column without a 
cast.  Small values (in the int range work fine though).

On 7.3 I get:

files=# create table test (cola bigint);
CREATE
files=# insert into test values (99);
ERROR:  column cola is of type 'bigint' but expression is of type 
'double precision'
You will need to rewrite or cast the expression

On 7.2.1 this works correctly:

files=# create table test (cola bigint);
CREATE
files=# insert into test values (99);
INSERT 108683 1

thanks,
--Barry



---(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] Bug/Change in behavior for 7.3 vs 7.2.1

2002-08-15 Thread Greg Copeland


Dang it...meant to mention that the other day when I was working on
those python patches.  I had to place tick marks (single quote) around
the number and it was converted correctly.

gcope=# insert into a values ( 99 ) ;
ERROR:  column a is of type 'bigint' but expression is of type 'double
precision'
You will need to rewrite or cast the expression
gcope=# insert into a values ( '99' ) ;
INSERT 25115 1

Greg


On Thu, 2002-08-15 at 20:03, Barry Lind wrote:
 I was just testing my product running on a 7.3 snapshot from a few days 
 ago.  And I ran into the following change in behavior that I consider a 
 bug.  You can no long insert large values into a bigint column without a 
 cast.  Small values (in the int range work fine though).
 
 On 7.3 I get:
 
 files=# create table test (cola bigint);
 CREATE
 files=# insert into test values (99);
 ERROR:  column cola is of type 'bigint' but expression is of type 
 'double precision'
 You will need to rewrite or cast the expression
 
 On 7.2.1 this works correctly:
 
 files=# create table test (cola bigint);
 CREATE
 files=# insert into test values (99);
 INSERT 108683 1
 
 thanks,
 --Barry
 
 
 
 ---(end of broadcast)---
 TIP 2: you can get off all lists at once with the unregister command
 (send unregister YourEmailAddressHere to [EMAIL PROTECTED])




signature.asc
Description: This is a digitally signed message part

[HACKERS] more fulltextindex stuff

2002-08-15 Thread Christopher Kings-Lynne


Hi,

I notice that the new default for the contrib Makefiles is to build
libfti.so, etc. instead of the old fti.so.  Won't this cause dump restore
problems for everyone already using the contrib?  Anyone mind if I change it
to use MODULES instead of MODULE_big for backwards compatibility?

Chris


---(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] Coding help

2002-08-15 Thread Matthew T. O'Connor


Hello, I'm playing with creating an auto vacuum daemon, but it is my first 
time inside the pg source code and I'm a bit lost.

I have gotten as far as having a vacuum daemon created on postmaster startup.  
It's just a fork from the postmaster, cribbed mostly from the stat collector 
code. 

Inside the main loop of the autovac daemon, I am trying to call vacuum() but I 
get the following error: 
FATAL:  VACUUM cannot be executed from a function

I don't understand why it thinks I'm in a function, I believe the error is 
being generated by this is vacuum.c:

/* Running VACUUM from a function would free the function context */
if (vacstmt-vacuum  !MemoryContextContains(QueryContext, vacstmt))
elog(ERROR, %s cannot be executed from a function, stmttype);

So, I assume it has something to do with the memory context that I'm in when I 
call the vacuum command, so I have been playing with switching contexts and 
such, but I have had no luck, obviously I don't really know what is going on 
here.

The code snippet that is actually calling the vacuum looks like this:
{
VacuumStmt *n = makeNode(VacuumStmt);
n-vacuum = true;
n-analyze = false;
n-full = false;
n-freeze = false;
n-verbose = false;
n-relation = NULL;
n-va_cols = NIL;
vacuum(n);  
}

Any help would be greatly appreciated.

Thanks,

Matt

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Open 7.3 items

2002-08-15 Thread Bruce Momjian


Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
  If we don't suffix global users with '@', a global user named 'dave'
  could not attach to a database called 'db1' as himself if a user called
  'dave@db1' existed.
 
 No, it's the other way around (assuming you check user before user@db):
 the existence of a global user would prevent similarly-named local users
 from connecting.  This does not strike me as too terrible, assuming that
 there are not very many global users.

Yes, something like that.  It could go either way.  I never actually
coded the double checking.

-- 
  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 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

[HACKERS] Finally, a list of big companies using PostgreSQL for serious projects. Why use PostgreSQL? Here's why.

2002-08-15 Thread Justin Clift


Hi everyone,

It's taken some real time and effort to get this list together, but many
good people and many good companies have decided to stand up and show
off that they use PostgreSQL for *serious* projects.  For some, it's
even Mission Critical.

To compliment this, PostgreSQL Inc. is now offering support contracts up
to and including 24/7 with worldwide coverage.

http://techdocs.postgresql.org/techdocs/supportcontracts.php

For an idea of how big these companies are, here are a few of the
biggest:

Affymetrix - A market leader in the creation of state-of-the-art tools
for the genetic research industry, uses PostgreSQL in their
Transcriptome Project to store data about large-scale RNA expression
experiments derived from high-density GeneChip® microarrays.

Afilias - A global provider of domain name registry services, currently
managing the first new generic extension launched on the Internet,
.INFO.  This Ireland-based company manages over 900,000 domain names and
over 10 million records in its PostgreSQL-backed database.

BASF - The worlds largest chemical company, uses PostgreSQL to store the
data for their U.S. Agribusiness E-Commerce website.

Cognitivity - The online e-Learning provider uses PostgreSQL as the
preferred database for their presentation and management software.

Journyx - The acknowledged world-wide leader in web based time and
expense tracking, with over 1 million end users.  They use PostgreSQL
for all their internal database operations across all unix versions
(Linux, BSD, AIX, Solaris, with MacOS X arriving shortly).

Royal - The modern Royal Typewriter company, their online e-Commerce
website stores everything using PostgreSQL.

The American Chemical Society - The largest professional organization of
Chemists in the world, with over 165,000 members, and a website that
receives more than 12 million visits every day.  Their Journal Archive
stores 125 years of full publications (2.5 million pages, more than 1
terabyte of data) using PostgreSQL.

Tsutaya - Japan's largest video rental chain, uses PostgreSQL for a
multi-gigabyte, billion-record-plus business information database.

I'm pretty sure everyone will appreciate the significance of these
companies showing their support.

:-)

Regards and best wishes,

Justin Clift

-- 
My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there.
   - Indira Gandhi

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Companies involved in development

2002-08-15 Thread Bruce Momjian


Robert Treat wrote:
 On Thu, 2002-08-15 at 17:13, Ross J. Reedstrom wrote:
  On Thu, Aug 15, 2002 at 11:05:07AM -0400, Bruce Momjian wrote:
   I think we are going to see more company-funded developers working on
   PostgreSQL.  There are a handful now, but I can see lots more coming.
   I am going to work on getting those funding companies more visibility. 
   We originally were concerned that such involvement may harm the
   development process, but history has shown that it has only been a huge
   benefit for the community.
  
  I agree, and it's also true that while the visibility of all you
  paid-to-hack types is high, the fact that you _are_ paid, and by wha
  companies, is not.
  
 
 At a minimum we could have people attach a company name to their
 developer bios (http://developer.postgresql.org/bios.php) if their
 company pays them to hack on postgresql. (at the developers discretion
 of course) At the least I would think companies like postgresql inc
 would benefit from publicity that we employee X number of pg
 developers.
 
 We could also generate a list of companies sponsoring postgresql
 development, but we'd have to come up with some criterion as to what it
 means to be a sponsors. For example, a coworker and I were discussing a
 patch he is getting ready to submit this morning while we were on the
 clock. While our company doesn't have an issue with this,  I don't know
 that I would say they sponsor postgresql development, they just happen
 to employ two guys who are more involved than most and will hack code if
 it scratches our particular itch.

Yea, that is a tough one, but anyone who is submitting patches regularly
and does _some_ work on company time is eligible, I think.

-- 
  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 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] Companies involved in development

2002-08-15 Thread Bruce Momjian


Ross J. Reedstrom wrote:
 On Thu, Aug 15, 2002 at 11:05:07AM -0400, Bruce Momjian wrote:
  I think we are going to see more company-funded developers working on
  PostgreSQL.  There are a handful now, but I can see lots more coming.
  I am going to work on getting those funding companies more visibility. 
  We originally were concerned that such involvement may harm the
  development process, but history has shown that it has only been a huge
  benefit for the community.
 
 I agree, and it's also true that while the visibility of all you
 paid-to-hack types is high, the fact that you _are_ paid, and by wha
 companies, is not.
 
 Just recently, one of the GnuE developers has been running on about SapDB,
 and mentioned how they've got '100 paid developers at SAP' and seemed to
 think that since GreatBridge died, pgsql is back to all volunteer. The
 fact that GB wasn't the first nor the only nor the last corp. funding
 pgsql development was clearly missed, even among a relatively PG savvy
 user community (GnuE is the GNU/Enterprise middleware system, and is is
 pgsql as its primary developement backend http://www.gnuenterprise.org/ )

Yes, it is very invisible now.

-- 
  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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Open 7.3 issues

2002-08-15 Thread Bruce Momjian



OK, I removed this 7.3 open item and added a documentation item for the
release notes:

  Mention foreign keys and SERIAL dependencies will not be in 7.2 loaded tables

---

Rod Taylor wrote:
  Dependency - have pg_dump auto-create dependencies when loading 7.2.X
  data? 
  
  Are we as far as we can go here?
 
 The only trouble maker is foreign keys.  If there was a nice way of
 finding foreign keys in 7.2 and prior it probably would have been
 implemented a long time ago in pg_dump :)
 
 Something in the release notes about how the foreign key dependency
 stuff only works if they drop all current foreign keys (drop trigger)
 and re-add them via alter table add foreign key is suggested.
 
 Worst case scenario for Foreign keys is they will have what they always
 had.
 
 
 ---(end of broadcast)---
 TIP 4: Don't 'kill -9' the postmaster
 

-- 
  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 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] Open 7.3 issues

2002-08-15 Thread Bruce Momjian


Neil Conway wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
  remove interfaces/ssl if not improved
  
  I am ready to yank this.
 
 Agreed.

Done and item removed.


  allow specification of configuration files in a different directory?
  
  Anyone working on this?
 
 Not sure we need this for 7.3 -- unless (a) someone steps up to do the
 work (b) there is some consensus on the design, I don't have a problem
 with letting this wait for 7.4

Removed.  No one has jumped on this.  Added to TODO:

* Allow configuration files to be specified in a different directory

  Allow PL/PgSQL functions to return sets
  
  Is anyone working on this?
 
 I am. It should be ready in time for 7.3.

OK.

-- 
  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 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Finally, a list of big companies using PostgreSQL for serious projects. Why use PostgreSQL? Here's why.

2002-08-15 Thread Sean Chittenden


 It's taken some real time and effort to get this list together, but many
 good people and many good companies have decided to stand up and show
 off that they use PostgreSQL for *serious* projects.  For some, it's
 even Mission Critical.

Erm, Cisco uses PostgreSQL as an embedded database in equipment.  Not
widely known, but under some IOS products, it's PostgreSQL doing the
data storage and not Oracle.

http://www-search.cisco.com/pcgi-bin/search/public.pl?q=postgresqlsearchselector=0num=10sa=Search

http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/chse/1105/1_3/install/appl_cli.htm

(search for PostgreSQL)

-sc

-- 
Sean Chittenden

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Open 7.3 issues

2002-08-15 Thread Bruce Momjian


Joe Conway wrote:
  Fix bytea to not encode input string
  
  Not sure we can do these.
 
 As I said, it isn't clear to me how this can be fixed without a fe/be 
 protocol change. But if someone can point me in the direction of a 
 viable fix for 7.3, I'll dive in.

OK, item removed and added to TODO:

* Prevent mismatch of frontend/backend encodings from converting bytea
  data from being interpreted as encoded strings

-- 
  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] Open 7.3 issues

2002-08-15 Thread Bruce Momjian


Tom Lane wrote:
  I'm concerned, but in the few moments I've had to play with this, what 
  looked like the obvious fix didn't seem to work (I was hacking on glibc 
  itself though).
 
 Red Hat's internal opinion seems to be that #define NO_MKTIME_BEFORE_1970
 is a sufficient answer.  I consider that well to the south of sucking,
 but at this point I really doubt that we have the time to implement a
 better answer for 7.3.  A better answer seems to mean writing our own
 interface to the zic timezone database.  Make no mistake: I think we
 should do that, and will do it eventually.  I just doubt it'll happen
 in the next two weeks.  And again, I do not feel we should hold up 7.3
 to wait for a solution.

So everyone's conclusion is that we can't patch over this problem with a
patched up version on the link line, so I will just add it to the TODO
list:

* Fix glibc's mktime() to handle pre-1970's dates

Do we have a way to detect this bug and warn users somehow?

-- 
  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] Open 7.3 issues

2002-08-15 Thread Bruce Momjian


Peter Eisentraut wrote:
 Bruce Momjian writes:
 
  Socket permissions - only install user can access db by default
  unix_socket_permissions in postgresql.conf
 
 This is dead.

Removed, still on TODO.

  glibc and mktime() - fix?
 
 Leave it be.  If someone really needs time information from before 1970
 (and who does?) he wouldn't use an OS that doesn't support it anyway.
 There are several platforms that don't have complete time information
 before 1947 and we've lived with those, too.

Removed.  Added to TODO.

 
  ecpg and bison issues - solved?
 
 A release is cooking.  1.49b was released just a few days ago.  Assuming
 that it is sane and no final release comes out before beta, we might ship
 our beta built with their beta and coordinate with them to make a final
 release during our beta.  It's a bit risky, but the more testing we can
 provide to them the faster they will get a release out.

We will see...

 
  fix BeOS and QNX4 ports
 
  Should we ship 7.3 without these ports?
 
 Porters usually appear during beta.

Well, we don't really want porting fixes during beta unless we can help
it.  ;-)

  integrate or remove new libpqxx
  integrate or add to gborg Pg:DBD
 
  Seems like gborg is the place for these.
 
 I would volunteer to package libpq++ separately.
 
  move pg_resetxlog and pg_controldata to main tree, add -f flag
 
  That is me. I  will get to it.
 
 What does -f do?

There is concern that using pg_resetxlog by accident could cause
problems, so it will prompt the user for confirmation by default.  -f
(force) disables that confirmation.

-- 
  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 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

[HACKERS] where to put NO_MKTIME_BEFORE_1970?

2002-08-15 Thread Joe Conway


I'm running Red Hat 7.3 at home. For the fun of it, I put:
   #define NO_MKTIME_BEFORE_1970

into /src/include/port/linux.h and then did:
make clean
make all
make install
initdb
make installcheck

But I'm still getting the  1970 regression test failures. What else do 
I need to do?

Joe


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Admin nice-to-have's

2002-08-15 Thread Neil Conway


Scott Shattuck [EMAIL PROTECTED] writes:
 Allow DBA/Database Owner to log in even when max_connections has
 been reached so they can determine which queries are hung via
 pg_stat_activity etc. and perform any other needed work to restore
 stability.

Allowing the database owner to login seems definately wrong: it's not
unusual for many of the normal database clients to run as the owner of
the database they operate on. So this would effectively disable the
max_connections limit in this situation.

I don't see a major problem with allowing postgres to login if the
connection limit is hit (although I'm not sure it's worth the worry,
when 'kill a backend executing SELECT ; psql template1 postgres' works
as-is).

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

Re: [HACKERS] Better handling of parse errors

2002-08-15 Thread Bruce Momjian



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.

---


Gavin Sherry wrote:
 On Wed, 14 Aug 2002, Tom Lane wrote:
 
  Gavin Sherry [EMAIL PROTECTED] writes:
   ... do we want to modify every 7.2 error message?
  
  Nyet ... but I don't think tacking an offset onto the end of
  parse error at or near foo messages is likely to cause the
  sort of generalized havoc you suggest ...
 
 In that case, attached is a patch which locates the beginning of the
 offending token more efficiently (per your suggestion of using
 scanbuf). The new patch does the same as before:
 
 template1=# select * frum pg_class;
 ERROR:  parser: parse error at or near frum at character 10
 
 It also implement's Tom's suggestion:
 
 template1=# select * from pg_class where\g
 ERROR:  parse: parse error at end of input
 
 Gavin

Content-Description: 

[ Attachment, 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) 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 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [HACKERS] Admin nice-to-have's

2002-08-15 Thread Bruce Momjian


Neil Conway wrote:
 Scott Shattuck [EMAIL PROTECTED] writes:
  Allow DBA/Database Owner to log in even when max_connections has
  been reached so they can determine which queries are hung via
  pg_stat_activity etc. and perform any other needed work to restore
  stability.
 
 Allowing the database owner to login seems definately wrong: it's not
 unusual for many of the normal database clients to run as the owner of
 the database they operate on. So this would effectively disable the
 max_connections limit in this situation.
 
 I don't see a major problem with allowing postgres to login if the
 connection limit is hit (although I'm not sure it's worth the worry,
 when 'kill a backend executing SELECT ; psql template1 postgres' works
 as-is).

You would have to do it the unix kernel way when the PROC structure
fills;  it keeps the last slot open and only lets root use it.  If this
is desirable, I can add it to TODO.

-- 
  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 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] Open 7.3 items, with names

2002-08-15 Thread Bruce Momjian



I have added the names of the people who have the power to complete each
item.  It may not be the original author.

---

  P O S T G R E S Q L

  7 . 3  O P E NI T E M S


Current at ftp://candle.pha.pa.us/pub/postgresql/open_items.

Source Code Changes
---
Point-in-time recovery - status? (J.R., Richard)
Allow easy display of usernames in a group (pg_hba.conf uses groups now)
Reindex/btree shrinkage - does reindex need work, can btree be shrunk?
display locks - ready? (Bruce)
Prepared statements - ready?  (Tom)
Schema handling - ready? interfaces? client apps?
ecpg and bison issues - solved?  (Michael)
improve macros in new tuple header code (Manfred)
have pg_dumpall dump out db privilege and per-user/db settings
fix BeOS and QNX4 ports
fix implicit type coercions that are worse
integrate or remove new libpqxx
integrate or add to gborg Pg:DBD
handle lack of secondary passwords  (Bruce)
move pg_resetxlog and pg_controldata to main tree, add -f flag  (Bruce)
Allow PL/PgSQL functions to return sets  (Neil)
Agree on PGXLOG/-X handling  (Thomas)

Documentation Changes
-
Mention foreign keys and SERIAL dependencies will not be in 7.2 loaded tables
Document need to add permissions to loaded functions and languages


-- 
  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 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

[HACKERS] SET SCHEMA?

2002-08-15 Thread Oliver Elphick


Would it be useful to implement the SET SCHEMA command from SQL92? (I
assume it's also in 99.)

I guess that SET SCHEMA should change the front of the search path, so
that it would change the schema reported by current_schema().  It would
be a simplified form of SET SEARCH_PATH.
  
-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight, UK
http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 Praying always with all prayer and supplication in the
  Spirit, and watching thereunto with all perseverance 
  and supplication for all saints.   Ephesians 6:18


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Bug/Change in behavior for 7.3 vs 7.2.1

2002-08-15 Thread Tom Lane


Barry Lind [EMAIL PROTECTED] writes:
 You can no long insert large values into a bigint column without a 
 cast.

This seems to be fallout from the move to tighten up implicit coercions
(cf http://archives.postgresql.org/pgsql-hackers/2002-04/msg00528.php
as well as lots of earlier discussions).

I said right along that this topic needed more debate, but we haven't
gotten back to looking at it.  We have a number of other nasty behaviors
in current sources that trace back to altering the set of available
coercions.

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

Re: [HACKERS] SET SCHEMA?

2002-08-15 Thread Christopher Kings-Lynne


 Would it be useful to implement the SET SCHEMA command from SQL92? (I
 assume it's also in 99.)

 I guess that SET SCHEMA should change the front of the search path, so
 that it would change the schema reported by current_schema().  It would
 be a simplified form of SET SEARCH_PATH.

Hrm - it would be sort of silly to launch an all-new standards-compliant
schema support without it?

Chris


---(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] Coding help

2002-08-15 Thread Tom Lane


Matthew T. O'Connor [EMAIL PROTECTED] writes:
 I have gotten as far as having a vacuum daemon created on postmaster startup.
 It's just a fork from the postmaster, cribbed mostly from the stat collector 
 code. 

This will not get you very far, because the stat collector is not a real
backend.  The checkpointer process might be a better example, but it's
not quite a real backend either.  You need to be a real backend to
access shared buffers, locking, etc.

 I don't understand why it thinks I'm in a function,

Because CurrentMemoryContext is not QueryContext (presumably you never
set QueryContext at all).  This is a pretty cheesy test but I can't
think of a better one offhand...

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Open 7.3 issues

2002-08-15 Thread Tom Lane


Bruce Momjian [EMAIL PROTECTED] writes:
 What does -f do?

 There is concern that using pg_resetxlog by accident could cause
 problems, so it will prompt the user for confirmation by default.  -f
 (force) disables that confirmation.

pg_resetxlog already has an -f switch, and I do not think you should
change its semantics.  At least not without putting up a better argument
than the above.  Anyone who's running pg_resetxlog had already better
know what they're doing.

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

93 matches

Mail list logo