Re: [HACKERS] Open 7.3 items
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? Joe ---(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] Bug with CREATE CONSRAINT TRIGGER and attisdropped
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> CREATE CONSTRAINT TRIGGER doesn't respect attisdropped. Unfortunately I
> really don't have the time to submit a patch at the moment - sorry :(
> test=# create constraint trigger "$1" after insert or update on "slave" from
> master not deferrable initially immediate for each row execute procedure
> "RI_FKey_check_ins" ('$1', 'slave', 'master', 'UNSPECIFIED', 'a', 'x');
I'm not sure this is a bug. For CREATE CONSTRAINT TRIGGER to complain
at trigger creation time, you'd have to make it assume that it
understood the contents of the parameters passed to the trigger.
That seems like a bad idea; I'm willing to settle for run-time
detection instead.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Bug with CREATE CONSRAINT TRIGGER and attisdropped
CREATE CONSTRAINT TRIGGER doesn't respect attisdropped. Unfortunately I
really don't have the time to submit a patch at the moment - sorry :(
ctest=# create table master (x int unique, y int4 unique);
NOTICE: CREATE TABLE / UNIQUE will create implicit index 'master_x_key' for
table 'master'
NOTICE: CREATE TABLE / UNIQUE will create implicit index 'master_y_key' for
table 'master'
CREATE TABLE
test=# create table slave (a int);
CREATE TABLE
test=# alter table master drop x;
ALTER TABLE
test=# create constraint trigger "$1" after insert or update on "slave" from
master not deferrable initially immediate for each row execute procedure
"RI_FKey_check_ins" ('$1', 'slave', 'master', 'UNSPECIFIED', 'a', 'x');
CREATE TRIGGER
test=# insert into master values (1);
INSERT 16982 1
test=# insert into slave values (2);
ERROR: constraint $1: table master does not have an attribute x
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] Open 7.3 issues
Joe Conway <[EMAIL PROTECTED]> writes: > Bruce Momjian wrote: >> Point-in-time recovery - ready for 7.3? >> >> This seems very unlikely now. Status? > It would be a shame to have to wait for 7.4 for this one. If a credible patch appears before the end of the month, great --- but the discussions so far have left me feeling that we're still a ways away from PITR. And I *don't* want to hold up 7.3 to wait for it. Learned that lesson with WAL for 7.1 ... >> glibc and mktime() - fix? >> >> I can do the work on this I need more info and no one seems to be >> conerned. > 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. 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] tsearch bug in 7.2.1?
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
[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])
Re: [HACKERS] Open 7.3 issues
Bruce Momjian wrote: > Point-in-time recovery - ready for 7.3? > > This seems very unlikely now. Status? It would be a shame to have to wait for 7.4 for this one. > glibc and mktime() - fix? > > I can do the work on this I need more info and no one seems to be > conerned. 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). > 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. I saw Neil's response. I'll jump in to help if he needs any. > > 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. Joe ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] contrib Makefiles
"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
Re: [HACKERS] contrib Makefiles
Christopher Kings-Lynne wrote: > 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??? > It does if you're not specific. Take a look at dblink.sql.in. All of the dblink functions are in one shared object file. e.g. CREATE OR REPLACE FUNCTION dblink (text,text) RETURNS setof int AS 'MODULE_PATHNAME','dblink' LANGUAGE 'c' WITH (isstrict); CREATE OR REPLACE FUNCTION dblink_tok (int,int) RETURNS text AS 'MODULE_PATHNAME','dblink_tok' LANGUAGE 'c' WITH (isstrict); ... etc. Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] contrib Makefiles
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > > Is it possible to have two different functions in the .so that > can be made > > into two different postgres funtions, both referencing the same .so? > > Certainly, what's the problem there? Offhand I can't think of any > contrib modules that only define one function... OK then, 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??? Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] contrib Makefiles
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > Is it possible to have two different functions in the .so that can be made > into two different postgres funtions, both referencing the same .so? Certainly, what's the problem there? Offhand I can't think of any contrib modules that only define one function... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Problem with EXTRACT() in current sources?
I believe that SELECT EXTRACT(EPOCH FROM TIMESTAMP '2001-02-16 20:38:40'); ahould give a fairly large integer --- in 7.2 I get 982373920. But CVS tip (without the int64-timestamp option) produces 982.35592. Broken, no? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] contrib Makefiles
Is it possible to have two different functions in the .so that can be made into two different postgres funtions, both referencing the same .so? Chris > -Original Message- > From: Peter Eisentraut [mailto:[EMAIL PROTECTED]] > Sent: Thursday, 15 August 2002 6:02 AM > To: Christopher Kings-Lynne > Cc: Hackers > Subject: Re: [HACKERS] contrib Makefiles > > > Christopher Kings-Lynne writes: > > > How can I modify it to build two different C files into two > different .so's? > > That is next to impossible in the current setup. > > -- > Peter Eisentraut [EMAIL PROTECTED] > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 issues
"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 ---(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
On Thu, 2002-08-15 at 00:01, Christopher Kings-Lynne 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 :) > > What about this. > > 1. Implement pg_get_foreignkey_def() or whatever I've done the parsing of foreign key triggers required in the past for various documentation purposes and it wasn't overly fun -- nor am I sure it's right in all cases. Find 3 triggers with is_constraint true between two tables that match argument sets, split argument list by comma, first 4 aren't so useful, the rest in pairs are source / destination columns. Foreign Key state (deferred, match, etc.) is in the function naming convention. If you want to give it a shot, feel free. Whatever method is in place will need to work on 7.3 for those who didn't use a newer pg_dump on the older database. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Documentation DTD
Rod Taylor <[EMAIL PROTECTED]> writes: > Anyone mind if we bump the DTD version to Docbook 4.2? Peter E. is the gatekeeper on that, I think --- he pushed us to 4.1 not long ago. If Peter's okay with 4.2, then full speed ahead ... regards, tom lane PS: pgsql-docs is probably the more appropriate forum for this discussion. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 issues
Bruce Momjian <[EMAIL PROTECTED]> writes: > remove interfaces/ssl if not improved > > I am ready to yank this. Agreed. > 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. > 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 > Allow PL/PgSQL functions to return sets > > Is anyone working on this? I am. It should be ready in time for 7.3. 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])
Re: [HACKERS] [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
On Thu, 15 Aug 2002, Bruce Momjian wrote: > I would like to know how to move this item forward. Right now (i.e., in 7.2), the only two options we have for moving the log file to a different spindle are mounting it on pg_xlog and using a symlink. I doubt many people do the the former, and if they do they do not need an option to init_db to move the logfile away from its default location. So I propose we just continue to use the symlink method for the moment, until we agree on another way to store the log file location within the data directory, and at that time we implement the code to do that. Note that if we don't move forward at all, we're still left in the symlink situation, with the exception that you init_db, move the log directory and create the symlink by hand, and then start up the database. So this partial move forward makes no difference to the symlink argument. cjs -- Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 issues
> > 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 :) 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. Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
I would like to know how to move this item forward. --- Tom Lane wrote: > Curt Sampson <[EMAIL PROTECTED]> writes: > > ... just for the record I'm with the "don't > > use an environment variable" crowd here, too. It's way, way to easy > > to start up with the wrong setting in your environment. > > What he said ... > > > Oh, and yes, it does need to be changable after an initdb. Say you > > start out with only one disk on your system, but add a second disk > > later, and want to move the log to that? > > Sure, there should be *a* way to do that. It does not have to be as > easy as "change an environment variable". And in fact the primary > objection to this patch is exactly that it is *not* as easy as "change > an environment variable" --- what you get if you just change your > environment variable is not a moved xlog, but a broken database. > Possibly an irredeemably broken database. > > 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 issues
> 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
Re: [HACKERS] [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
Curt Sampson <[EMAIL PROTECTED]> writes: > ... just for the record I'm with the "don't > use an environment variable" crowd here, too. It's way, way to easy > to start up with the wrong setting in your environment. What he said ... > Oh, and yes, it does need to be changable after an initdb. Say you > start out with only one disk on your system, but add a second disk > later, and want to move the log to that? Sure, there should be *a* way to do that. It does not have to be as easy as "change an environment variable". And in fact the primary objection to this patch is exactly that it is *not* as easy as "change an environment variable" --- what you get if you just change your environment variable is not a moved xlog, but a broken database. Possibly an irredeemably broken database. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Standard replication interface?
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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Open 7.3 issues
Here are some comments on the open 7.3 items. We have to start pairing this down if we are going to hit beta in 2.5 weeks: --- 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 --- Socket permissions - only install user can access db by default unix_socket_permissions in postgresql.conf Are we going to do anything with sockets permissions to tighten things up? I know of one big client where PostgreSQL got a bad rap for being open to all local users by default. Point-in-time recovery - ready for 7.3? This seems very unlikely now. Status? Allow easy display of usernames in a group (pg_hba.conf uses groups now) I was hoping for something on this because we are now using groups for pg_hba.conf. If not, we can add it to TODO. I think it is already there. Reindex/btree shrinkage - does reindex need work, can btree be shrunk? Can we do anything here? display locks - ready? This one is waiting to be applied. Win32 - timefame? Seems like a non-issue for 7.3. Prepared statements - ready? New version submitted recently. Is it ready to be applied? Schema handling - ready? interfaces? client apps? We need a posting describing what interfaces/applictions need to look at for schemas. Dependency - have pg_dump auto-create dependencies when loading 7.2.X data? Are we as far as we can go here? glibc and mktime() - fix? I can do the work on this I need more info and no one seems to be conerned. ecpg and bison issues - solved? Do we have a fallback position on this if bison can't get a fixed version? improve macros in new tuple header code have pg_dumpall dump out db privilege and per-user/db settings These need to be done. fix BeOS and QNX4 ports Should we ship 7.3 without these ports? fix implicit type coercions that are worse Details? remove interfaces/ssl if not improved I am ready to yank this. integrate or remove new libpqxx integrate or add to gborg Pg:DBD Seems like gborg is the place for these. allow specification of configuration files in a different directory? Anyone working on this? handle lack of secondary passwords? We are discussing this so I think we can get this done soon. move pg_resetxlog and pg_controldata to main tree, add -f flag That is me. I will get to it. 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. Fix bytea to not encode input string Fix db, function, language permissions on 7.2 database loads Not sure we can do these. Agree on PGXLOG/-X handling This is still an open item. -- 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] [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
On Tue, 13 Aug 2002, scott.marlowe wrote: > My non-coding vote goes with Tom Lane on this. initdb can set pg_xlog, > and if you need to change it, use symlinks. I've not been following this thread, and thus I suppose I missed my opportunity to vote, but just for the record I'm with the "don't use an environment variable" crowd here, too. It's way, way to easy to start up with the wrong setting in your environment. The log is part of the database. Therefore you should store the information on its location along with the rest of the database information. The idea is, you pass *one* piece of information to your program when you start it (in this case the database data directory location), and all of the rest of the information comes from there. Then you have guaranteed consistency. How the log location is stored within that area, I'm not so fussy about. If a symlink is so terrible, why not put this information in the database config file? Oh, and yes, it does need to be changable after an initdb. Say you start out with only one disk on your system, but add a second disk later, and want to move the log to that? cjs -- Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] python patch
Thanks.
-Greg
On Wed, 2002-08-14 at 22:34, Bruce Momjian wrote:
>
> OK, I have applied all three of Greg's python patches.
>
> ---
>
> Christopher Kings-Lynne wrote:
> > Yep - alright, just commit it I guess.
> >
> > Chris
> >
> > > -Original Message-
> > > From: Greg Copeland [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, 15 August 2002 11:09 AM
> > > To: Rod Taylor
> > > Cc: Christopher Kings-Lynne; Bruce Momjian; PostgresSQL Hackers Mailing
> > > List
> > > Subject: Re: [HACKERS] python patch
> > >
> > >
> > > Well, I tend to agree with that. Overall, I can't say that I see bad
> > > things coming out of accepting the patch as is. It's not exactly
> > > causing an extra join or other wise a significant waste of resources.
> > > At worst, it appears to be ambiguous. Since Christopher has not offered
> > > any additional follow up, can we assume that he agrees? In not, please
> > > let me know and I'll resubmit patch #2.
> > >
> > > In the mean time, patches #1 and #3 should be good to go. Bruce, feel
> > > free to apply those whenever time allows.
> > >
> > > Thanks,
> > > Greg Copeland
> > >
> > >
> > > On Mon, 2002-08-12 at 18:33, Rod Taylor wrote:
> > > > All of that said, the cost of the check is so small it may save someones
> > > > ass some day when they have a corrupted catalog and the below
> > > > assumptions are no longer true.
> > > >
> > > > On Mon, 2002-08-12 at 18:40, Greg Copeland wrote:
> > > > > On Sun, 2002-08-11 at 21:15, Christopher Kings-Lynne wrote:
> > > > > > > Not a problem. I would rather them be correct.
> > > > > > >
> > > > > > > Worth noting that the first patch is what attempts to fix
> > > the long ->
> > > > > > > int overflow issue. The second patch attempts to resolve
> > > "attisdropped"
> > > > > > > column use issues with the python scripts. The third
> > > patch addresses
> > > > > > > issues generated by the implicate to explicate use of "cascade".
> > > > > > >
> > > > > > > I assume your reservations are only with the second patch
> > > and not the
> > > > > > > first and third patches?
> > > > > >
> > > > > > Correct. I'm pretty sure you don't need to exclude
> > > attisdropped from the
> > > > > > primary key list because all it's doing is finding the
> > > column that a primary
> > > > > > key is over and that should never be over a dropped column. I can't
> > > > > > remember what you said the second query did?
> > > > >
> > > > >
> > > > > Hmmm. Sounds okay but I'm just not sure that holds true (as I
> > > > > previously stated, I'm ignorant on the topic). Obviously
> > > I'll defer to
> > > > > you on this.
> > > > >
> > > > > Here's the queries and what they do:
> > > > >
> > > > >
> > > > > >From pg.py:
> > > > > Used to locate primary keys -- or so the comment says. It
> > > does create a
> > > > > dictionary of keys and attribute values for each returned row so I
> > > > > assume it really is attempting to do something of the like.
> > > > >
> > > > > SELECT pg_class.relname, pg_attribute.attname
> > > > > FROM pg_class, pg_attribute, pg_index
> > > > > WHERE pg_class.oid = pg_attribute.attrelid AND
> > > > > pg_class.oid = pg_index.indrelid AND
> > > > > pg_index.indkey[0] = pg_attribute.attnum AND
> > > > > pg_index.indisprimary = 't' AND
> > > > > pg_attribute.attisdropped = 'f' ;
> > > > >
> > > > > So, everyone is in agreement that any attribute which is indexed as a
> > > > > primary key will never be able to have attisdtopped = 't'?
> > > > >
> > > > > According to the code:
> > > > > SELECT pg_attribute.attname, pg_type.typname
> > > > > FROM pg_class, pg_attribute, pg_type
> > > > > WHERE pg_class.relname = '%s' AND
> > > > > pg_attribute.attnum > 0 AND
> > > > > pg_attribute.attrelid = pg_class.oid AND
> > > > > pg_attribute.atttypid = pg_type.oid AND
> > > > > pg_attribute.attisdropped = 'f' ;
> > > > >
> > > > > is used to obtain all attributes (column names) and their types for a
> > > > > given table ('%s'). It then attempts to build a column/type
> > > cache. I'm
> > > > > assuming that this really does need to be there. Please correct
> > > > > accordingly.
> > > > >
> > > > >
> > > > > >From syscat.py:
> > > > > SELECT bc.relname AS class_name,
> > > > > ic.relname AS index_name, a.attname
> > > > > FROM pg_class bc, pg_class ic, pg_index i, pg_attribute a
> > > > > WHERE i.indrelid = bc.oid AND i.indexrelid = bc.oid
> > > > > AND i.indkey[0] = a.attnum AND a.attrelid = bc.oid
> > > > > AND i.indproc = '0'::oid AND a.attisdropped = 'f'
> > > > > ORDER BY class_name, index_name, attname ;
> > > > >
> > > > > According to the nearby documentation, it's supposed to be fetching a
> > > > > list of "all simple indicies". If that's the case, is it
> > > safe to assume
> > > > > that any indexed column will never have attisdropped = 't'? If so, we
> > > > > can re
Re: [HACKERS] python patch
OK, I have applied all three of Greg's python patches.
---
Christopher Kings-Lynne wrote:
> Yep - alright, just commit it I guess.
>
> Chris
>
> > -Original Message-
> > From: Greg Copeland [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, 15 August 2002 11:09 AM
> > To: Rod Taylor
> > Cc: Christopher Kings-Lynne; Bruce Momjian; PostgresSQL Hackers Mailing
> > List
> > Subject: Re: [HACKERS] python patch
> >
> >
> > Well, I tend to agree with that. Overall, I can't say that I see bad
> > things coming out of accepting the patch as is. It's not exactly
> > causing an extra join or other wise a significant waste of resources.
> > At worst, it appears to be ambiguous. Since Christopher has not offered
> > any additional follow up, can we assume that he agrees? In not, please
> > let me know and I'll resubmit patch #2.
> >
> > In the mean time, patches #1 and #3 should be good to go. Bruce, feel
> > free to apply those whenever time allows.
> >
> > Thanks,
> > Greg Copeland
> >
> >
> > On Mon, 2002-08-12 at 18:33, Rod Taylor wrote:
> > > All of that said, the cost of the check is so small it may save someones
> > > ass some day when they have a corrupted catalog and the below
> > > assumptions are no longer true.
> > >
> > > On Mon, 2002-08-12 at 18:40, Greg Copeland wrote:
> > > > On Sun, 2002-08-11 at 21:15, Christopher Kings-Lynne wrote:
> > > > > > Not a problem. I would rather them be correct.
> > > > > >
> > > > > > Worth noting that the first patch is what attempts to fix
> > the long ->
> > > > > > int overflow issue. The second patch attempts to resolve
> > "attisdropped"
> > > > > > column use issues with the python scripts. The third
> > patch addresses
> > > > > > issues generated by the implicate to explicate use of "cascade".
> > > > > >
> > > > > > I assume your reservations are only with the second patch
> > and not the
> > > > > > first and third patches?
> > > > >
> > > > > Correct. I'm pretty sure you don't need to exclude
> > attisdropped from the
> > > > > primary key list because all it's doing is finding the
> > column that a primary
> > > > > key is over and that should never be over a dropped column. I can't
> > > > > remember what you said the second query did?
> > > >
> > > >
> > > > Hmmm. Sounds okay but I'm just not sure that holds true (as I
> > > > previously stated, I'm ignorant on the topic). Obviously
> > I'll defer to
> > > > you on this.
> > > >
> > > > Here's the queries and what they do:
> > > >
> > > >
> > > > >From pg.py:
> > > > Used to locate primary keys -- or so the comment says. It
> > does create a
> > > > dictionary of keys and attribute values for each returned row so I
> > > > assume it really is attempting to do something of the like.
> > > >
> > > > SELECT pg_class.relname, pg_attribute.attname
> > > > FROM pg_class, pg_attribute, pg_index
> > > > WHERE pg_class.oid = pg_attribute.attrelid AND
> > > > pg_class.oid = pg_index.indrelid AND
> > > > pg_index.indkey[0] = pg_attribute.attnum AND
> > > > pg_index.indisprimary = 't' AND
> > > > pg_attribute.attisdropped = 'f' ;
> > > >
> > > > So, everyone is in agreement that any attribute which is indexed as a
> > > > primary key will never be able to have attisdtopped = 't'?
> > > >
> > > > According to the code:
> > > > SELECT pg_attribute.attname, pg_type.typname
> > > > FROM pg_class, pg_attribute, pg_type
> > > > WHERE pg_class.relname = '%s' AND
> > > > pg_attribute.attnum > 0 AND
> > > > pg_attribute.attrelid = pg_class.oid AND
> > > > pg_attribute.atttypid = pg_type.oid AND
> > > > pg_attribute.attisdropped = 'f' ;
> > > >
> > > > is used to obtain all attributes (column names) and their types for a
> > > > given table ('%s'). It then attempts to build a column/type
> > cache. I'm
> > > > assuming that this really does need to be there. Please correct
> > > > accordingly.
> > > >
> > > >
> > > > >From syscat.py:
> > > > SELECT bc.relname AS class_name,
> > > > ic.relname AS index_name, a.attname
> > > > FROM pg_class bc, pg_class ic, pg_index i, pg_attribute a
> > > > WHERE i.indrelid = bc.oid AND i.indexrelid = bc.oid
> > > > AND i.indkey[0] = a.attnum AND a.attrelid = bc.oid
> > > > AND i.indproc = '0'::oid AND a.attisdropped = 'f'
> > > > ORDER BY class_name, index_name, attname ;
> > > >
> > > > According to the nearby documentation, it's supposed to be fetching a
> > > > list of "all simple indicies". If that's the case, is it
> > safe to assume
> > > > that any indexed column will never have attisdropped = 't'? If so, we
> > > > can remove that check from the file as well. Worth pointing out, this
> > > > is from syscat.py, which is sample source and not used as actual
> > > > interface. So, worse case, it would appear to be redundant in nature
> > > > with no harm done.
> > > >
> > > > This should conc
Re: [HACKERS] Another python patch -- minor
Patch applied. Thanks.
---
Greg Copeland wrote:
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> This fixes some text as well as enforces the use of "drop table cascade"
> since we moved from an implicate to explicate implementation.
>
> Please find attached the func.py patch.
>
> Sorry these are not all one single patch. I really hadn't planned on
> doing all this...especially not tonight. ;)
>
> Greg Copeland
>
>
>
[ text/x-patch is unsupported, treating like TEXT/PLAIN ]
> Index: func.py
> ===
> RCS file: /projects/cvsroot/pgsql-server/src/interfaces/python/tutorial/func.py,v
> retrieving revision 1.5
> diff -u -r1.5 func.py
> --- func.py 2000/10/02 03:46:24 1.5
> +++ func.py 2002/08/08 03:47:04
> @@ -9,7 +9,7 @@
> This module is designed for being imported from python prompt
>
> In order to run the samples included here, first create a connection
> -using :cnx = advanced.DB(...)
> +using :cnx = func.DB(...)
>
> The "..." should be replaced with whatever arguments you need to open an
> existing database. Usually all you need is the name of the database and,
> @@ -189,13 +189,13 @@
> print "DROP FUNCTION add_em(int4, int4)"
> print "DROP FUNCTION one()"
> print
> - print "DROP TABLE EMP"
> + print "DROP TABLE EMP CASCADE"
> pgcnx.query("DROP FUNCTION clean_EMP()")
> pgcnx.query("DROP FUNCTION high_pay()")
> pgcnx.query("DROP FUNCTION new_emp()")
> pgcnx.query("DROP FUNCTION add_em(int4, int4)")
> pgcnx.query("DROP FUNCTION one()")
> - pgcnx.query("DROP TABLE EMP")
> + pgcnx.query("DROP TABLE EMP CASCADE")
>
> # main demo function
> def demo(pgcnx):
-- End of PGP section, PGP failed!
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] python patch
Patch applied. Thanks.
---
Greg Copeland wrote:
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> Well, that certainly appeared to be very straight forward. pg.py and
> syscat.py scripts were both modified. pg.py uses it to cache a list of
> pks (which is seemingly does for every db connection) and various
> attributes. syscat uses it to walk the list of system tables and
> queries the various attributes from these tables.
>
> In both cases, it seemingly makes sense to apply what you've requested.
>
> Please find attached the quested patch below.
>
> Greg
>
>
> On Wed, 2002-08-07 at 22:16, Christopher Kings-Lynne wrote:
> > > I don't have a problem looking into it but I can't promise I can get it
> > > right. My python skills are fairly good...my postgres internal skills
> > > are still sub-par IMO.
> > >
> > > From a cursory review, if attisdropped is true then the attribute/column
> > > should be ignored/skipped?! Seems pretty dang straight forward.
> >
> > Basically, yep. Just grep the source code for pg_attribute most likely...
> >
> > I'm interested in knowing what it uses pg_attribute for as well...?
> >
> > 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
>
[ text/x-patch is unsupported, treating like TEXT/PLAIN ]
> Index: pg.py
> ===
> RCS file: /projects/cvsroot/pgsql-server/src/interfaces/python/pg.py,v
> retrieving revision 1.9
> diff -u -r1.9 pg.py
> --- pg.py 2002/03/19 13:20:52 1.9
> +++ pg.py 2002/08/08 03:29:48
> @@ -69,7 +69,8 @@
> WHERE pg_class.oid =
>pg_attribute.attrelid AND
> pg_class.oid =
>pg_index.indrelid AND
> pg_index.indkey[0] =
>pg_attribute.attnum AND
> - pg_index.indisprimary =
>'t'""").getresult():
> + pg_index.indisprimary = 't' AND
> + pg_attribute.attisdropped =
>'f'""").getresult():
> self.__pkeys__[rel] = att
>
> # wrap query for debugging
> @@ -111,7 +112,8 @@
> WHERE pg_class.relname = '%s' AND
> pg_attribute.attnum > 0 AND
> pg_attribute.attrelid = pg_class.oid
>AND
> - pg_attribute.atttypid = pg_type.oid"""
> + pg_attribute.atttypid = pg_type.oid AND
> + pg_attribute.attisdropped = 'f'"""
>
> l = {}
> for attname, typname in self.db.query(query % cl).getresult():
> Index: tutorial/syscat.py
> ===
> RCS file: /projects/cvsroot/pgsql-server/src/interfaces/python/tutorial/syscat.py,v
> retrieving revision 1.7
> diff -u -r1.7 syscat.py
> --- tutorial/syscat.py2002/05/03 14:21:38 1.7
> +++ tutorial/syscat.py2002/08/08 03:29:48
> @@ -37,7 +37,7 @@
> FROM pg_class bc, pg_class ic, pg_index i, pg_attribute a
> WHERE i.indrelid = bc.oid AND i.indexrelid = bc.oid
> AND i.indkey[0] = a.attnum AND a.attrelid = bc.oid
> - AND i.indproc = '0'::oid
> + AND i.indproc = '0'::oid AND a.attisdropped = 'f'
> ORDER BY class_name, index_name, attname""")
> return result
>
> @@ -48,6 +48,7 @@
> WHERE c.relkind = 'r' and c.relname !~ '^pg_'
> AND c.relname !~ '^Inv' and a.attnum > 0
> AND a.attrelid = c.oid and a.atttypid = t.oid
> +AND a.attisdropped = 'f'
> ORDER BY relname, attname""")
> return result
>
-- End of PGP section, PGP failed!
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] python patch
Patch applied. Thanks.
---
Greg Copeland wrote:
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> Okay, I read
> http://archives.postgresql.org/pgsql-bugs/2002-06/msg00086.php and never
> saw a fix offered up. Since I'm gearing up to use Postgres and Python
> soon, I figured I'd have a hand at trying to get this sucker addressed.
> Apologies if this has already been plugged. I looked in the archives
> and never saw a response.
>
> At any rate, I must admit I don't think I fully understand the
> implications of some of the changes I made even though they appear to be
> straight forward. We all know the devil is in the details. Anyone more
> knowledgeable is requested to review my changes. :(
>
> I also updated the advanced.py script in a somewhat nonsensical fashion
> to make use of an int8 field in an effort to test this change. It seems
> to run okay, however, this is by no means an all exhaustive test. So,
> it's possible that a bumpy road may lay ahead for some. On the other
> hand...overflows (hopefully) previously lurked (long -> int conversion).
>
> This is my first submission. Please be kind if I submitted to the wrong
> list. ;)
>
> Thank you,
> Greg Copeland
>
[ text/x-diff is unsupported, treating like TEXT/PLAIN ]
> ? lib_pgmodule.so.0.0
> ? postgres-python.patch
> ? tutorial/advanced.pyc
> Index: pgmodule.c
> ===
> RCS file: /projects/cvsroot/pgsql-server/src/interfaces/python/pgmodule.c,v
> retrieving revision 1.38
> diff -u -r1.38 pgmodule.c
> --- pgmodule.c2002/03/29 07:45:39 1.38
> +++ pgmodule.c2002/08/08 02:46:12
> @@ -289,23 +289,26 @@
> {
> case INT2OID:
> case INT4OID:
> - case INT8OID:
> case OIDOID:
> typ[j] = 1;
> break;
>
> + case INT8OID:
> + typ[j] = 2;
> + break;
> +
> case FLOAT4OID:
> case FLOAT8OID:
> case NUMERICOID:
> - typ[j] = 2;
> + typ[j] = 3;
> break;
>
> case CASHOID:
> - typ[j] = 3;
> + typ[j] = 4;
> break;
>
> default:
> - typ[j] = 4;
> + typ[j] = 5;
> break;
> }
> }
> @@ -1797,23 +1800,26 @@
> {
> case INT2OID:
> case INT4OID:
> - case INT8OID:
> case OIDOID:
> typ[j] = 1;
> break;
>
> + case INT8OID:
> + typ[j] = 2;
> + break;
> +
> case FLOAT4OID:
> case FLOAT8OID:
> case NUMERICOID:
> - typ[j] = 2;
> + typ[j] = 3;
> break;
>
> case CASHOID:
> - typ[j] = 3;
> + typ[j] = 4;
> break;
>
> default:
> - typ[j] = 4;
> + typ[j] = 5;
> break;
> }
> }
> @@ -1846,10 +1852,14 @@
> break;
>
> case 2:
> - val = PyFloat_FromDouble(strtod(s,
>NULL));
> + val = PyLong_FromLong(strtol(s, NULL,
>10));
> break;
>
> case 3:
> + val = PyFloat_FromDouble(strtod(s,
>NULL));
> + break;
> +
> + case 4:
> {
> int mult =
>1;
>
> @@ -1946,11 +1956,14 @@
> {
> case INT2OID:
> case INT4OID:
> - case INT8OID:
> case OIDOID:
> typ[j] = 1;
> break;
>
> + case INT8OID:
> + typ[j] = 2;
> + break;
> +
>
[HACKERS] Standard replication interface?
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. Think this has any merit? Greg Copeland signature.asc Description: This is a digitally signed message part
Re: [HACKERS] python patch
Yep - alright, just commit it I guess.
Chris
> -Original Message-
> From: Greg Copeland [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, 15 August 2002 11:09 AM
> To: Rod Taylor
> Cc: Christopher Kings-Lynne; Bruce Momjian; PostgresSQL Hackers Mailing
> List
> Subject: Re: [HACKERS] python patch
>
>
> Well, I tend to agree with that. Overall, I can't say that I see bad
> things coming out of accepting the patch as is. It's not exactly
> causing an extra join or other wise a significant waste of resources.
> At worst, it appears to be ambiguous. Since Christopher has not offered
> any additional follow up, can we assume that he agrees? In not, please
> let me know and I'll resubmit patch #2.
>
> In the mean time, patches #1 and #3 should be good to go. Bruce, feel
> free to apply those whenever time allows.
>
> Thanks,
> Greg Copeland
>
>
> On Mon, 2002-08-12 at 18:33, Rod Taylor wrote:
> > All of that said, the cost of the check is so small it may save someones
> > ass some day when they have a corrupted catalog and the below
> > assumptions are no longer true.
> >
> > On Mon, 2002-08-12 at 18:40, Greg Copeland wrote:
> > > On Sun, 2002-08-11 at 21:15, Christopher Kings-Lynne wrote:
> > > > > Not a problem. I would rather them be correct.
> > > > >
> > > > > Worth noting that the first patch is what attempts to fix
> the long ->
> > > > > int overflow issue. The second patch attempts to resolve
> "attisdropped"
> > > > > column use issues with the python scripts. The third
> patch addresses
> > > > > issues generated by the implicate to explicate use of "cascade".
> > > > >
> > > > > I assume your reservations are only with the second patch
> and not the
> > > > > first and third patches?
> > > >
> > > > Correct. I'm pretty sure you don't need to exclude
> attisdropped from the
> > > > primary key list because all it's doing is finding the
> column that a primary
> > > > key is over and that should never be over a dropped column. I can't
> > > > remember what you said the second query did?
> > >
> > >
> > > Hmmm. Sounds okay but I'm just not sure that holds true (as I
> > > previously stated, I'm ignorant on the topic). Obviously
> I'll defer to
> > > you on this.
> > >
> > > Here's the queries and what they do:
> > >
> > >
> > > >From pg.py:
> > > Used to locate primary keys -- or so the comment says. It
> does create a
> > > dictionary of keys and attribute values for each returned row so I
> > > assume it really is attempting to do something of the like.
> > >
> > > SELECT pg_class.relname, pg_attribute.attname
> > > FROM pg_class, pg_attribute, pg_index
> > > WHERE pg_class.oid = pg_attribute.attrelid AND
> > > pg_class.oid = pg_index.indrelid AND
> > > pg_index.indkey[0] = pg_attribute.attnum AND
> > > pg_index.indisprimary = 't' AND
> > > pg_attribute.attisdropped = 'f' ;
> > >
> > > So, everyone is in agreement that any attribute which is indexed as a
> > > primary key will never be able to have attisdtopped = 't'?
> > >
> > > According to the code:
> > > SELECT pg_attribute.attname, pg_type.typname
> > > FROM pg_class, pg_attribute, pg_type
> > > WHERE pg_class.relname = '%s' AND
> > > pg_attribute.attnum > 0 AND
> > > pg_attribute.attrelid = pg_class.oid AND
> > > pg_attribute.atttypid = pg_type.oid AND
> > > pg_attribute.attisdropped = 'f' ;
> > >
> > > is used to obtain all attributes (column names) and their types for a
> > > given table ('%s'). It then attempts to build a column/type
> cache. I'm
> > > assuming that this really does need to be there. Please correct
> > > accordingly.
> > >
> > >
> > > >From syscat.py:
> > > SELECT bc.relname AS class_name,
> > > ic.relname AS index_name, a.attname
> > > FROM pg_class bc, pg_class ic, pg_index i, pg_attribute a
> > > WHERE i.indrelid = bc.oid AND i.indexrelid = bc.oid
> > > AND i.indkey[0] = a.attnum AND a.attrelid = bc.oid
> > > AND i.indproc = '0'::oid AND a.attisdropped = 'f'
> > > ORDER BY class_name, index_name, attname ;
> > >
> > > According to the nearby documentation, it's supposed to be fetching a
> > > list of "all simple indicies". If that's the case, is it
> safe to assume
> > > that any indexed column will never have attisdropped = 't'? If so, we
> > > can remove that check from the file as well. Worth pointing out, this
> > > is from syscat.py, which is sample source and not used as actual
> > > interface. So, worse case, it would appear to be redundant in nature
> > > with no harm done.
> > >
> > > This should conclude the patched items offered in the second patch.
> > >
> > > What ya think?
> > >
> > > Thanks,
> > > Greg
> > >
> > >
> >
> >
> >
> > ---(end of broadcast)---
> > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
>
>
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddre
[HACKERS] Documentation DTD
Anyone mind if we bump the DTD version to Docbook 4.2? This consists on all users who wish to build docs on installing the 4.2 DTD set, and updating some depreciated tags within the sgml files. comment -> remark docinfo -> appendixinfo, chapterinfo, bookinfo, etc. 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. 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. ---(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] python patch
Well, I tend to agree with that. Overall, I can't say that I see bad
things coming out of accepting the patch as is. It's not exactly
causing an extra join or other wise a significant waste of resources.
At worst, it appears to be ambiguous. Since Christopher has not offered
any additional follow up, can we assume that he agrees? In not, please
let me know and I'll resubmit patch #2.
In the mean time, patches #1 and #3 should be good to go. Bruce, feel
free to apply those whenever time allows.
Thanks,
Greg Copeland
On Mon, 2002-08-12 at 18:33, Rod Taylor wrote:
> All of that said, the cost of the check is so small it may save someones
> ass some day when they have a corrupted catalog and the below
> assumptions are no longer true.
>
> On Mon, 2002-08-12 at 18:40, Greg Copeland wrote:
> > On Sun, 2002-08-11 at 21:15, Christopher Kings-Lynne wrote:
> > > > Not a problem. I would rather them be correct.
> > > >
> > > > Worth noting that the first patch is what attempts to fix the long ->
> > > > int overflow issue. The second patch attempts to resolve "attisdropped"
> > > > column use issues with the python scripts. The third patch addresses
> > > > issues generated by the implicate to explicate use of "cascade".
> > > >
> > > > I assume your reservations are only with the second patch and not the
> > > > first and third patches?
> > >
> > > Correct. I'm pretty sure you don't need to exclude attisdropped from the
> > > primary key list because all it's doing is finding the column that a primary
> > > key is over and that should never be over a dropped column. I can't
> > > remember what you said the second query did?
> >
> >
> > Hmmm. Sounds okay but I'm just not sure that holds true (as I
> > previously stated, I'm ignorant on the topic). Obviously I'll defer to
> > you on this.
> >
> > Here's the queries and what they do:
> >
> >
> > >From pg.py:
> > Used to locate primary keys -- or so the comment says. It does create a
> > dictionary of keys and attribute values for each returned row so I
> > assume it really is attempting to do something of the like.
> >
> > SELECT pg_class.relname, pg_attribute.attname
> > FROM pg_class, pg_attribute, pg_index
> > WHERE pg_class.oid = pg_attribute.attrelid AND
> > pg_class.oid = pg_index.indrelid AND
> > pg_index.indkey[0] = pg_attribute.attnum AND
> > pg_index.indisprimary = 't' AND
> > pg_attribute.attisdropped = 'f' ;
> >
> > So, everyone is in agreement that any attribute which is indexed as a
> > primary key will never be able to have attisdtopped = 't'?
> >
> > According to the code:
> > SELECT pg_attribute.attname, pg_type.typname
> > FROM pg_class, pg_attribute, pg_type
> > WHERE pg_class.relname = '%s' AND
> > pg_attribute.attnum > 0 AND
> > pg_attribute.attrelid = pg_class.oid AND
> > pg_attribute.atttypid = pg_type.oid AND
> > pg_attribute.attisdropped = 'f' ;
> >
> > is used to obtain all attributes (column names) and their types for a
> > given table ('%s'). It then attempts to build a column/type cache. I'm
> > assuming that this really does need to be there. Please correct
> > accordingly.
> >
> >
> > >From syscat.py:
> > SELECT bc.relname AS class_name,
> > ic.relname AS index_name, a.attname
> > FROM pg_class bc, pg_class ic, pg_index i, pg_attribute a
> > WHERE i.indrelid = bc.oid AND i.indexrelid = bc.oid
> > AND i.indkey[0] = a.attnum AND a.attrelid = bc.oid
> > AND i.indproc = '0'::oid AND a.attisdropped = 'f'
> > ORDER BY class_name, index_name, attname ;
> >
> > According to the nearby documentation, it's supposed to be fetching a
> > list of "all simple indicies". If that's the case, is it safe to assume
> > that any indexed column will never have attisdropped = 't'? If so, we
> > can remove that check from the file as well. Worth pointing out, this
> > is from syscat.py, which is sample source and not used as actual
> > interface. So, worse case, it would appear to be redundant in nature
> > with no harm done.
> >
> > This should conclude the patched items offered in the second patch.
> >
> > What ya think?
> >
> > Thanks,
> > Greg
> >
> >
>
>
>
> ---(end of broadcast)---
> TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: [HACKERS] Domains and Indexes
I backed this out. It is part of a later patch still in the queue. --- Bruce Momjian wrote: > > [ Sorry for previous message saying it was added to queue.] > > Patch applied. Thanks. > > --- > > > Rod Taylor wrote: > > Appears there is a problem finding the opclass when indexing a domain. > > > > CREATE DOMAIN newint as int4; > > CREATE TABLE tab (col newint unique); > > ERROR: data type newint has no default operator class for access method > > "btree" > > You must specify an operator class for the index or define a > > default operator class for the data type > > > > > > Specifically, GetDefaultOpClass() finds 0 exact matches and 3 binary > > compatible matches. Fetching getBaseType() of the attribute fixes the > > problem for domains (see attachment). > > > > However, I have to wonder why GetDefaultOpClass doesn't simply use the > > first Binary Compatible opclass. When there is more than one usable it > > doesn't do anything useful. > > > > > > [ Attachment, skipping... ] > > > > > ---(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 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 > -- 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] Please, apply patch for contrib/tsearch
Patch applied. Thanks. --- Teodor Sigaev wrote: > CHANGES: > > August 13, 2002 > Use parser of OpenFTS v0.33. > > -- > Teodor Sigaev > [EMAIL PROTECTED] > [ application/gzip is not supported, skipping... ] > > ---(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 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] Domains and Indexes
[ Sorry for previous message saying it was added to queue.] Patch applied. Thanks. --- Rod Taylor wrote: > Appears there is a problem finding the opclass when indexing a domain. > > CREATE DOMAIN newint as int4; > CREATE TABLE tab (col newint unique); > ERROR: data type newint has no default operator class for access method > "btree" > You must specify an operator class for the index or define a > default operator class for the data type > > > Specifically, GetDefaultOpClass() finds 0 exact matches and 3 binary > compatible matches. Fetching getBaseType() of the attribute fixes the > problem for domains (see attachment). > > However, I have to wonder why GetDefaultOpClass doesn't simply use the > first Binary Compatible opclass. When there is more than one usable it > doesn't do anything useful. > > [ Attachment, skipping... ] > > ---(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 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] Domains and Indexes
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. --- Rod Taylor wrote: > Appears there is a problem finding the opclass when indexing a domain. > > CREATE DOMAIN newint as int4; > CREATE TABLE tab (col newint unique); > ERROR: data type newint has no default operator class for access method > "btree" > You must specify an operator class for the index or define a > default operator class for the data type > > > Specifically, GetDefaultOpClass() finds 0 exact matches and 3 binary > compatible matches. Fetching getBaseType() of the attribute fixes the > problem for domains (see attachment). > > However, I have to wonder why GetDefaultOpClass doesn't simply use the > first Binary Compatible opclass. When there is more than one usable it > doesn't do anything useful. > > [ Attachment, skipping... ] > > ---(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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 items
[EMAIL PROTECTED] (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. > Maybe I am missing something here but shouldnt db access really be part of the privileges system? If all we are talking about is a quick hack until this can be implemented correctly, what is the concern with having so much functionality in the hack? Why does it matter what the actual usernames can or cant be? For example you could just make everyone with a username NN@dbname (where N's are int) local accounts and then leave everything else alone. The only issue I could see with something like this would be that someone trying to use this hack wont be able to give their users names like pudgy@dbname, but who cares? I mean if you are giving access to a bunch of developers, how is it going to affect them if you tell them to login with 123456@yourdb instead of jsmith@yourdb? If they cant remember it or something maybe they can write it down? I dunno... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Inheritance
On Wed, 14 Aug 2002, Tom Lane wrote: > It's nonlocal constraints that are the problem, and here foreign keys > and UNIQUE constraints are certainly the canonical examples. Both of > these would be largely solved with table-spanning indexes I think. Note that the other obvious way to solve this would be to store all of the information inherited from the parent in the parent table, so that you don't have to do anything special to make all of the constraints and whatnot apply. cjs -- Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] another multibyte question
> Do any of the encodings with encoding max length > 1 have a constant > character size (e.g. unicode?). If so, how hard would it be to add > another member to pg_wchar_tbl, say: > > bool mblen_is_const; /* all chars = max bytes this charset */ > > Then those character sets code gain back much of the same speed > advantages as single byte character sets when it comes to string processing. Sounds interesting idea, but none of encodings currently PostgreSQL supports has fixed length character size. UCS-2/UCS-4 is such an encoding, we do not support it however. -- Tatsuo Ishii ---(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
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
Re: [HACKERS] Inheritance
Curt Sampson <[EMAIL PROTECTED]> writes: > That's my biggest fear as well. Here are a couple of possible > assertions we could make about supertables and subtables that have, > I think, some fairly far-reaching implications. CHECK-style constraints don't seem like a huge issue to me. We already have recursive ALTER TABLE ADD CONSTRAINT, and IIRC we do actually arrange for CHECK constraints on a parent to be inherited when a child is created. We could argue about whether, for example, non-recursive ADD CONSTRAINT should be disallowed or not --- but that's not any kind of implementation showstopper, just a definitional issue about flexibility vs. safety. It's nonlocal constraints that are the problem, and here foreign keys and UNIQUE constraints are certainly the canonical examples. Both of these would be largely solved with table-spanning indexes I think. What I'm not sure about is what other gotchas may be lurking... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Inheritance
On Wed, 14 Aug 2002, Tom Lane wrote: > I agree. Table-spanning indexes would be a large, complex, > difficult-to-get-right feature. Before diving into that we should get > some idea of just how we'd actually use them, and whether that's the > only big chunk of work standing between us and a more useful inheritance > feature. I'm afraid we might do all that effort and then discover there > are other showstoppers. That's my biggest fear as well. Here are a couple of possible assertions we could make about supertables and subtables that have, I think, some fairly far-reaching implications. 1. All constraints one places on a supertable must "work." That is, they must apply on all subtables as well, and must always be true on the supertable. For example, if I apply the constraint, "this int field must be no smaller than 1 and no larger than 100," to the supertable, this must apply to all subtables, and you must not be able to remove the constraint from just a subtable." 2. It must not be possible apply a constraint to a supertable that could be violated. 3. All constraints that one can apply to a non-inherited table in postgresql must also be able to be applied to a supertable. Depending on which of these you want to implement, and how you do it, you may get yourself into a position where you can create a table that that cannot have subtables, or cannot put certain constraints on supertables cjs -- Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Open 7.3 items
On Wed, 14 Aug 2002, Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > How about if we just document that they have to create a > > > postgres@template1 user before flipping the switch. That way, there is > > > no special user, no PG_INSTALLER file, and no double-tests for user > > > names. > > > > ... and no useful superuser account; if you can't connect to anything > > except template1 then you ain't much of a superuser. > > > > To get around that you'd have to create postgres@db1, postgres@db2, > > postgres@db3, etc etc. This would be a huge pain in the neck; I think > > it'd render the scheme impractical. (Keep in mind that anybody who'd be > > interested in this feature at all has probably got quite a number of > > databases to contend with.) > > Yes, I hear you, but that brings us around full-circle to the original > patch with one super-user who is the install user. > > 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, and having none seems to be unappealing. This is why I am back to > just the install user. I wouldn't be in favor of that. 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items
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. But I don't think it's a wise idea to design the thing in a way that makes it impossible to have more than one global user. If you don't like including all the pg_shadow entries in the flat file (though I really don't see any problem with that), could we replace PG_INSTALL with a pg_global_users config file that lists the global user names? I think it would be good enough to let this be hand-maintained, with initdb initializing it to contain the install user's name. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 items
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > How about if we just document that they have to create a > > postgres@template1 user before flipping the switch. That way, there is > > no special user, no PG_INSTALLER file, and no double-tests for user > > names. > > ... and no useful superuser account; if you can't connect to anything > except template1 then you ain't much of a superuser. > > To get around that you'd have to create postgres@db1, postgres@db2, > postgres@db3, etc etc. This would be a huge pain in the neck; I think > it'd render the scheme impractical. (Keep in mind that anybody who'd be > interested in this feature at all has probably got quite a number of > databases to contend with.) Yes, I hear you, but that brings us around full-circle to the original patch with one super-user who is the install user. 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, and having none seems to be unappealing. This is why I am back to just the install user. -- 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
On Wed, 14 Aug 2002, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I have no personal preference between period and @ or whatever. See if > > you can get some other votes for @ because most left @ when the ORDER BY > > idea came up from Marc. > > FWIW, I still lean to username@database, so I think we're roughly at a > tie. It would be good to get more votes ... Seeing as this is rumbling on I'll throw in my fraction of a vote. I too like the user@database form, partly because it 'reads'. On the other hand I can see the the reasons to like database.user and it does match the style of database.schema.object. Unfortunately for this second form, as '.' is a valid character in a database name then I can see this causing problems, especially with the behind the scenes combination of the two names. I don't see this problem with the '@' form because I can't see that character being used in a 'unqualified' user name. Hmmm...not sure that makes a terribly good arguement for my vote for 'user@db', is there a third choice for us confused folks to go for? A compromise: database@username ? [BTW, I did check and '@' seems to be a valid character in database and user names.] -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_dump output portability
On Wed, 2002-08-14 at 18:20, Bruce Momjian wrote: > Peter Eisentraut wrote: > > > I will vote against this as being a major loss of legibility. Perhaps > > > we could compromise on controlling it by a GUC variable, though. > > > > I was afraid of that, but to pick up the theme of the day, I'm not sure if > > I want to overcomplexify things that much. ;-) > > Tomorrow's theme is "sharing". :-) Brought to you by the letters S, Q, L and the number 99. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] anoncvs - here we go again!
On 14 Aug 2002, Oliver Elphick wrote: > > cvs server: Updating src/backend/utils/mb/conversion_procs/ascii_and_mic > cvs server: failed to create lock directory for > `/projects/cvsroot/pgsql-server/src/backend/utils/mb/conversion_procs/ascii_and_mic' >(/projects/cvsroot/pgsql-server/src/backend/utils/mb/conversion_procs/ascii_and_mic/#cvs.lock): > Permission denied > cvs server: failed to obtain dir lock in repository > `/projects/cvsroot/pgsql-server/src/backend/utils/mb/conversion_procs/ascii_and_mic' > cvs [server aborted]: read lock failed - giving up Damn, thought I had added a chown at the end of that command ... both are now fixed ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] encrypted passwords
Bruce Momjian <[EMAIL PROTECTED]> writes: > It also allowed auto-migration to encrypted passwords from an old dump > file. Ah, right, that was it: we wanted to be able to have a pg_dumpall script containing a mix of crypted and noncrypted passwords in CREATE USER commands be loaded either as-is, or have all the passwords forced to crypted form, depending on the setting of password_encryption. So we didn't really want the CREATE USER commands in the script to say exactly what to do. Therefore, in the design as released the CREATE USER commands emitted by pg_dumpall don't actually say either ENCRYPTED or UNENCRYPTED. We didn't see a need for ALREADY_CRYPTED either, figuring that it would actually be more reliable to deduce that by looking at the data than by having a separate flag for it. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] journaling in contrib ...
On Thu, 15 Aug 2002, Peter Eisentraut wrote: > Bruce Momjian writes: > > > OK, we got _that_ answer. Looks like gborg. Marc really wants to pump > > that up. > > I think if gborg had a different name and looked more like the main site, > more people would consider using it without feeling "kicked out". Well, that's the first I've heard of anything like that, but several points to make here ... Chris Ryan has been actively working with the www group working on the web towards addresssing issues with GBorg, and be, the 'main site' is currently in the process of getting totally overhauled by said group ... Nobody is being kicked out ... we now have an effective method of managing projects without them being part of the centrali distribution ... 'being kicked out', to me, would mean pushing them over to DB2+Sourceforge ;) ---(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
Bruce Momjian <[EMAIL PROTECTED]> writes: > How about if we just document that they have to create a > postgres@template1 user before flipping the switch. That way, there is > no special user, no PG_INSTALLER file, and no double-tests for user > names. ... and no useful superuser account; if you can't connect to anything except template1 then you ain't much of a superuser. To get around that you'd have to create postgres@db1, postgres@db2, postgres@db3, etc etc. This would be a huge pain in the neck; I think it'd render the scheme impractical. (Keep in mind that anybody who'd be interested in this feature at all has probably got quite a number of databases to contend with.) regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_dump output portability
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Most of these look like they would break a lot of people --- for
>> example, we can't just arbitrarily change the results of bool_out.
> That wouldn't help anyway. I meant to add code in pg_dump (and possibly
> the rule recompiler). That doesn't break anything.
Ah. But where exactly will you substitute true for 't'? I don't think
pg_dump necessarily knows enough to apply that transformation.
ruleutils could and probably should do it for bool constants, but that's
only a small part of pg_dump output.
>> You mean you'd rather eliminate the -N behavior, no? I'd vote for that.
> Yes. Or at least switch the default to "portable and readable".
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.
>> Again, I'm fairly suspicious of this; it seems likely to result in
>> failures to read in the data. You can't just leave data newlines as-is
>> for example.
> Why not? You'd end up with
> INSERT ... VALUES ('multi
> line
> literal', 'more data');
> This is accepted by PostgreSQL now, is legal SQL, and is arguably at least
> as readable as octal escape sequences. (Note I'm not talking about doing
> this in COPY, which is not portable anyway.)
Okay, I missed that context; I was thinking of COPY. Yeah, in string
literals in INSERT it seems fairly reasonable to do nothing to the data
except double ' and \. I am a little worried however about
character-set-encoding gotchas. Hiroshi or Tatsuo might have more
insight here.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] encrypted passwords
Tom Lane wrote: > Hmm. I thought it *was* done, but it looks like Bruce forgot to change > the actual guc.c value? The docs and postgresql.conf.sample claim the > default is true... > > 2002-06-14 21:29 momjian > > * doc/src/sgml/runtime.sgml, > src/backend/utils/misc/postgresql.conf.sample: Make encryption of > stored passwords the default, as discussed months ago. > > Seem to be one file short on that commit ... Fixed. > > (3) (Related to 2b above) Shouldn't we reject an attempt by the user > > to specify an un-encrypted password that matches the isMD5() test? > > No, see above. There are actually three cases here: entering a > previously encrypted password (in which case do nothing to it regardless > of the "encrypted" option), entering an uncrypted password with the > "encrypted" option (apply MD5 transform), or entering an uncrypted > password with the "unencrypted" option (do nothing). > > I suppose we could have instead invented an ALREADY_CRYPTED option > instead, but we didn't, for reasons I don't recall at the moment; > but I think it had something to do with making life easier for > pg_dumpall. I think there wasn't a reason to make the distinction because it could be detected automatically, and an admin copying a password from somewhere else could easily accidentally double-encrypt the password, which then wouldn't work. It also allowed auto-migration to encrypted passwords from an old dump file. -- 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] encrypted passwords
Neil Conway <[EMAIL PROTECTED]> writes: > A couple questions regarding encrypted passwords: > (1) There was talk of changing the default value of the > 'password_encryption' GUC variable for 7.3; AFAIK, this hasn't > happened yet. Should this be done? Hmm. I thought it *was* done, but it looks like Bruce forgot to change the actual guc.c value? The docs and postgresql.conf.sample claim the default is true... 2002-06-14 21:29 momjian * doc/src/sgml/runtime.sgml, src/backend/utils/misc/postgresql.conf.sample: Make encryption of stored passwords the default, as discussed months ago. Seem to be one file short on that commit ... > (2) What is the reasoning behind the current storage format of > MD5-encrypted passwords? The reasoning for the apparent leakage between encrypted and unencrypted formats is it allows pg_dumpall to reload an already-encrypted password, or an admin to copy-and-paste an encrypted password without knowing exactly what the password is. See the archives when this mechanism was being designed (about a year ago I think), if you want the full story. > (b) it makes it difficult to determine if the password is > *actually* encrypted, or whether the user just happened to > specify an (unencrypted) password of that form. By definition, if it looks like that then it's encrypted. I really doubt anyone will want to use a 35-character plaintext password... the apparent conflict is not going to happen in practice AFAICS. > (c) it limits us to using the MD5 algorithm. Nonsense. If we want another method, we just use another prefix. > (3) (Related to 2b above) Shouldn't we reject an attempt by the user > to specify an un-encrypted password that matches the isMD5() test? No, see above. There are actually three cases here: entering a previously encrypted password (in which case do nothing to it regardless of the "encrypted" option), entering an uncrypted password with the "encrypted" option (apply MD5 transform), or entering an uncrypted password with the "unencrypted" option (do nothing). I suppose we could have instead invented an ALREADY_CRYPTED option instead, but we didn't, for reasons I don't recall at the moment; but I think it had something to do with making life easier for pg_dumpall. > (4) The naming standard for system catalogs would dictate that the > 'passwd' field of pg_shadow actually be named 'usepasswd' or > something similar, wouldn't it? The same applies to the 'valuntil > field. Yeah, they are both ancient mistakes. It's not worth trying to fix now however; we'd just break client queries. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 items
OK, I have a new idea. Seems most don't like that 'postgres' is a special user in this context. How about if we just document that they have to create a postgres@template1 user before flipping the switch. That way, there is no special user, no PG_INSTALLER file, and no double-tests for user names. It doesn't give us a global user, but frankly, it seems that such a system is never going to work reliably. Trying to prevent namespace conflicts by checking for users without @ that may match will make @ a special character in the user namespace, and people won't like that. --- Tom Lane wrote: > Lamar Owen <[EMAIL PROTECTED]> writes: > > So the former plain 'postgres' user could still be such to us, to client > > programs, etc, but the backend would assume that that meant > > postgres@template1 -- no namespace collision, and the special case is that > > anyone@template1 has the behavior the unadorned plain user now has. > > The trouble with that scheme is that there is zero interoperability > between the plain-vanilla mode (postgres is postgres in pg_shadow) and > the @-mode (postgres is postgres@template1 in pg_shadow). Flip the > configuration switch, in either direction, and you can't log in anymore. > We'd almost have to make it a frozen-at-initdb setting so that initdb > would know which form to put into pg_shadow for the superuser, and so > that entry wouldn't break thereafter. > > The reason I like the "lowen" vs "lowen@somedb" pattern is that > database-global users can log in the same way whether the feature is > turned on or not; this eliminates the getting-started problem, as well > as the likelihood of shooting yourself in the foot. > > It is true that if you have a global user lowen you'd want to avoid > creating any local users lowen@somedb, and that the existing code > wouldn't be able to enforce that. We could possibly add a few lines > to CREATE USER to warn about this mistake. (It should be a warning not > an error, since if you have no intention of ever using the @-feature > then there's no reason to restrict your choice of usernames.) > > 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] pg_dump output portability
Peter Eisentraut wrote: > > I will vote against this as being a major loss of legibility. Perhaps > > we could compromise on controlling it by a GUC variable, though. > > I was afraid of that, but to pick up the theme of the day, I'm not sure if > I want to overcomplexify things that much. ;-) Tomorrow's theme is "sharing". :-) -- 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] encrypted passwords
Rod Taylor wrote: > On Wed, 2002-08-14 at 16:32, Neil Conway wrote: > > A couple questions regarding encrypted passwords: > > > > (1) There was talk of changing the default value of the > > 'password_encryption' GUC variable for 7.3; AFAIK, this hasn't > > happened yet. Should this be done? > > Since ODBC is capable of using the encryption and I presume JDBC also > is, what reason is there for not enforcing it's use? It was delayed until 7.3 so we had 7.2 client apps that understood it so an upgraded would continue to work with older clients. -- 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] encrypted passwords
Neil Conway wrote: > A couple questions regarding encrypted passwords: > > (1) There was talk of changing the default value of the > 'password_encryption' GUC variable for 7.3; AFAIK, this hasn't > happened yet. Should this be done? Strange. I had updated the docs and postgresql.conf, but not guc.c, where the default it set. Fixed now. > (2) What is the reasoning behind the current storage format of > MD5-encrypted passwords? At the moment, we "determine" that a > password is stored pre-hashed in pg_shadow by checking if it > begins with "md5" and is 35 characters long (the isMD5() macro in > libpq/crypt.h). This seems problematic, for a couple reasons: > > (a) it needlessly overloads the password field: that field > should store the password or the digest itself, not > meta-data about the authentication process. Yep. That is how FreeBSD handles the password string, and I just followed that. > (b) it makes it difficult to determine if the password is > *actually* encrypted, or whether the user just happened to > specify an (unencrypted) password of that form. Yep, good point. > (c) it limits us to using the MD5 algorithm. MD5 is not > looking as invincible as it once did, and having the > capability to support SHA1 or another algorithm without > too much pain would be nice. > > (3) (Related to 2b above) Shouldn't we reject an attempt by the user > to specify an un-encrypted password that matches the isMD5() test? > For example: > > nconway=# create user foo encrypted password > 'md5'; > CREATE USER > nconway=# create user foo2 encrypted password 'somethingelse'; > CREATE USER > nconway=# select usename, passwd from pg_shadow > where usename like 'foo%'; > usename | passwd > -+- > foo | md5 > foo2| md51b80a20a1b6cd86eb369f01009b739d3 > > (The first password is stored "as-is", the second is hashed before > being stored.) > > I don't see a need for the ability to specify pre-hashed passwords, > and it makes the whole process of determining the type of password > being used more complicated. Well, pg_dump actually loads in the encrypted passwords in that format, so yea, we do need to allow that. Basically, if you want to split out the encryption type from the encryption string, you will need a new pg_shadow column to handle that, and an update to CREATE USER to pass that flag in for pg_dump to use when reloading. > (4) The naming standard for system catalogs would dictate that the > 'passwd' field of pg_shadow actually be named 'usepasswd' or > something similar, wouldn't it? The same applies to the 'valuntil > field. Yes, not sure what other apps access that, but clearly it is inconsistent. Will it cause hardship to fix 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Fwd: Re: [HACKERS] journaling in contrib ...
interesting. >From: Peter Eisentraut <[EMAIL PROTECTED]> >To: Bruce Momjian <[EMAIL PROTECTED]> >CC: Tom Lane <[EMAIL PROTECTED]>,Gavin Sherry <[EMAIL PROTECTED]>, ><[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> >Subject: Re: [HACKERS] journaling in contrib ... >Date: Thu, 15 Aug 2002 00:01:41 +0200 (CEST) >MIME-Version: 1.0 >Received: from [64.49.215.143] by hotmail.com (3.2) with ESMTP id >MHotMailBF241D7B006A4004319C4031D78F0F510; Wed, 14 Aug 2002 14:58:24 -0700 >Received: from postgresql.org (postgresql.org [64.49.215.8])by >relay2.pgsql.com (Postfix) with ESMTPid F0ED2EDFC30; Wed, 14 Aug 2002 >17:58:05 -0400 (EDT) >Received: from localhost (postgresql.org [64.49.215.8])by postgresql.org >(Postfix) with ESMTP id B278F47583Efor <[EMAIL PROTECTED]>; Wed, >14 Aug 2002 17:58:00 -0400 (EDT) >Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])by postgresql.org >(Postfix) with SMTP id A91A14754A3for <[EMAIL PROTECTED]>; Wed, >14 Aug 2002 17:57:59 -0400 (EDT) >Received: (qmail 26637 invoked by uid 0); 14 Aug 2002 21:58:00 - >Received: from pd902f0d4.dip0.t-ipconnect.de (217.2.240.212) by >mail.gmx.net (mp002-rz3) with SMTP; 14 Aug 2002 21:58:00 - >From pgsql-hackers-owner Wed, 14 Aug 2002 14:59:23 -0700 >X-X-Sender: [EMAIL PROTECTED] >In-Reply-To: <[EMAIL PROTECTED]> >Message-ID: ><[EMAIL PROTECTED]> >X-Virus-Scanned: by AMaViS new-20020517 >Precedence: bulk >Sender: [EMAIL PROTECTED] > >Bruce Momjian writes: > > > OK, we got _that_ answer. Looks like gborg. Marc really wants to pump > > that up. > >I think if gborg had a different name and looked more like the main site, >more people would consider using it without feeling "kicked out". > >-- >Peter Eisentraut [EMAIL PROTECTED] > > >---(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 _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ---(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] pg_dump output portability
Tom Lane writes:
> Most of these look like they would break a lot of people --- for
> example, we can't just arbitrarily change the results of bool_out.
That wouldn't help anyway. I meant to add code in pg_dump (and possibly
the rule recompiler). That doesn't break anything.
> You mean you'd rather eliminate the -N behavior, no? I'd vote for that.
Yes. Or at least switch the default to "portable and readable".
> Again, I'm fairly suspicious of this; it seems likely to result in
> failures to read in the data. You can't just leave data newlines as-is
> for example.
Why not? You'd end up with
INSERT ... VALUES ('multi
line
literal', 'more data');
This is accepted by PostgreSQL now, is legal SQL, and is arguably at least
as readable as octal escape sequences. (Note I'm not talking about doing
this in COPY, which is not portable anyway.)
> > * The expression reverse-engineering code outputs ::text and similar casts
> > in many cases. These should be CAST().
>
> I will vote against this as being a major loss of legibility. Perhaps
> we could compromise on controlling it by a GUC variable, though.
I was afraid of that, but to pick up the theme of the day, I'm not sure if
I want to overcomplexify things that much. ;-)
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Open 7.3 items
Bruce Momjian writes: > OK, what I didn't want to do we to over-complexify That's reasonable, but not when you break other things along the way that were themselves meant to decomplexify things. > something that is for only a few users. If it's only for a few users, please send private patches to them. Face it, it's not going to happen. It's going to be in the release notes, everyone's going to see it, and there's going to be a Slashdot thread about how "they" broke the password files. So let's design a feature for everyone. -- 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] contrib Makefiles
Christopher Kings-Lynne writes: > How can I modify it to build two different C files into two different .so's? That is next to impossible in the current setup. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] journaling in contrib ...
Bruce Momjian writes: > OK, we got _that_ answer. Looks like gborg. Marc really wants to pump > that up. I think if gborg had a different name and looked more like the main site, more people would consider using it without feeling "kicked out". -- Peter Eisentraut [EMAIL PROTECTED] ---(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
Lamar Owen <[EMAIL PROTECTED]> writes: > So the former plain 'postgres' user could still be such to us, to client > programs, etc, but the backend would assume that that meant > postgres@template1 -- no namespace collision, and the special case is that > anyone@template1 has the behavior the unadorned plain user now has. The trouble with that scheme is that there is zero interoperability between the plain-vanilla mode (postgres is postgres in pg_shadow) and the @-mode (postgres is postgres@template1 in pg_shadow). Flip the configuration switch, in either direction, and you can't log in anymore. We'd almost have to make it a frozen-at-initdb setting so that initdb would know which form to put into pg_shadow for the superuser, and so that entry wouldn't break thereafter. The reason I like the "lowen" vs "lowen@somedb" pattern is that database-global users can log in the same way whether the feature is turned on or not; this eliminates the getting-started problem, as well as the likelihood of shooting yourself in the foot. It is true that if you have a global user lowen you'd want to avoid creating any local users lowen@somedb, and that the existing code wouldn't be able to enforce that. We could possibly add a few lines to CREATE USER to warn about this mistake. (It should be a warning not an error, since if you have no intention of ever using the @-feature then there's no reason to restrict your choice of usernames.) regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] encrypted passwords
On Wed, 2002-08-14 at 16:32, Neil Conway wrote: > A couple questions regarding encrypted passwords: > > (1) There was talk of changing the default value of the > 'password_encryption' GUC variable for 7.3; AFAIK, this hasn't > happened yet. Should this be done? Since ODBC is capable of using the encryption and I presume JDBC also is, what reason is there for not enforcing it's use? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 items
On Wednesday 14 August 2002 03:49 pm, Bruce Momjian wrote: > Lamar Owen wrote: > > On Wednesday 14 August 2002 03:29 pm, Vince Vielhaber wrote: > > > Hate to complicate things more, but back to a global username, say > > > you have user "lowen" that should have access to all databases. What > > places. So I guess the solution is that wherever a user name is to be > > stored, the fully qualified form must be used and checked against, with > > @template1 being a 'this user is everywhere' shorthand. > Yes, Vince is on to something with his quote above. > If we have users with and without @, we get into the situation where > users without @ may become users with @ when their usernames collide > with existing user/db combinations already created. The point is that > those two namespaces do collide and will cause confusion. But that's the exact problem I was trying to address -- as far as the backend is concerned, there isn't a user without @ -- the incoming connection from a user without @ is translated into a connection coming from user@template1. > Then you start to get into the situation where you always add @ and make > @template1 a special case. However, remember that this flag can be > turned on and off after initdb, so you need to be able to get in to set > things up without great complexity _and_ the @template1 would not be > passed in from the client, if for no other reason that the username is > only 32 characters. It is the backend doing the flagging, and therefore > the user can't say 'I am dave@templatge1' vs 'I am dave@connectdb'. Ok, how do I as a client specify the @dbname for the user? By the database I'm connecting to? That IS a wrinkle. But it does make sense, as lowen@pari won't be able to connect to any other database, right? So, where's this new notation going to get used, again? I must have misunderstood something. So, if we have a namespace collision -- then we have to make the implementation have the restriction that a global username can't exist as a database-specific username -- but two or more database-specific usernames can be the same. So, have a trigger on insertion of a user that checks for an existing user attached to template1 (again, for consistency -- installation wide templates are in template1 -- installation-wide users should be too) -- and then aborts the CREATE USER if so. > This is how I got to the installuser hack in the first place. In fact, > even the install user, typically 'postgres' has a problem because if you > create 'postgres@db1', 'postgres' will have trouble connecing to db1 as > themselves. I think we can live with one user who is special/global, but > not more than one because of the confusion it would create. If you say CREATE USER lowen@pari for the syntax, the create user trips the trigger, which checks for lowen@template1 and aborts if so. CREATE USER lowen@template1 does the same, checking for ANY user lowen. Namespace collision averted? CREATE USER lowen would be the same as CREATE USER lowen@connecteddb, so that the subsuperuser for connecteddb can just CREATE USER without qualifying -- the command line createdb could take the @dbname argument, splitting it out and connecting to the proper database. This has ramifications, I admit. And just saying that unqualified CREATE USER's should create the user@template1 introduces its own problems. > I can change the way this works, but we need a solution without holes. Trigger on the holes. But if I can't (or shouldn't) be able to specify the @dbname from the client, there is GOING to be a namespace collision if installation-wide users of ANY name are allowed (which is what you've already said -- just repeating for emphasis). Or we will have to forbid the postgres user from being reused -- trigger on CREATE USER and abort if user=postgres, I guess. Now as to the toggling of the feature -- what happens when you have lowen@pari and lowen@wgcr coexisting, and you turn off the feature? Which password becomes valid for the resultant singular user lowen? IMHO, if two or more users of the same name occurs, then you shouldn't be able to turn the feature off. I know you've already put alot of work into this, Bruce. But what if the feature isn't toggled, but always there, just waiting to be exploited by CREATE USER user@db, with the default CREATE USER always putting the user into association with the currently connected database? Is there bad overhead involved? Is it something that could break installations not using the feature? Or should CREATE USER with an unqualified username default to @template1 (what I originally thought it should). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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
On Wednesday 14 August 2002 03:55 pm, Vince Vielhaber wrote: > On Wed, 14 Aug 2002, Lamar Owen wrote: > > If the user 'lowen' is then expanded to 'lowen@template1' it would be > > stored that way -- and lowen@template1 is different from lowen@pari, for > > But maybe I'm just misunderstanding the implementation. > > I may be too, but what's wrong with just "lowen" being shorthand for > 'this user is everywhere'? Does it also mean that we'd have a user > postgres@template1? WE could still use the form without @template1, but the backend would assume the @template1 user was being meant when the unqualified shorthand was used. So the former plain 'postgres' user could still be such to us, to client programs, etc, but the backend would assume that that meant postgres@template1 -- no namespace collision, and the special case is that anyone@template1 has the behavior the unadorned plain user now has. I do see Bruce's points, however. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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] encrypted passwords
A couple questions regarding encrypted passwords: (1) There was talk of changing the default value of the 'password_encryption' GUC variable for 7.3; AFAIK, this hasn't happened yet. Should this be done? (2) What is the reasoning behind the current storage format of MD5-encrypted passwords? At the moment, we "determine" that a password is stored pre-hashed in pg_shadow by checking if it begins with "md5" and is 35 characters long (the isMD5() macro in libpq/crypt.h). This seems problematic, for a couple reasons: (a) it needlessly overloads the password field: that field should store the password or the digest itself, not meta-data about the authentication process. (b) it makes it difficult to determine if the password is *actually* encrypted, or whether the user just happened to specify an (unencrypted) password of that form. (c) it limits us to using the MD5 algorithm. MD5 is not looking as invincible as it once did, and having the capability to support SHA1 or another algorithm without too much pain would be nice. (3) (Related to 2b above) Shouldn't we reject an attempt by the user to specify an un-encrypted password that matches the isMD5() test? For example: nconway=# create user foo encrypted password 'md5'; CREATE USER nconway=# create user foo2 encrypted password 'somethingelse'; CREATE USER nconway=# select usename, passwd from pg_shadow where usename like 'foo%'; usename | passwd -+- foo | md5 foo2| md51b80a20a1b6cd86eb369f01009b739d3 (The first password is stored "as-is", the second is hashed before being stored.) I don't see a need for the ability to specify pre-hashed passwords, and it makes the whole process of determining the type of password being used more complicated. (4) The naming standard for system catalogs would dictate that the 'passwd' field of pg_shadow actually be named 'usepasswd' or something similar, wouldn't it? The same applies to the 'valuntil field. Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] journaling in contrib ...
On Wed, 2002-08-14 at 12:47, Marc G. Fournier wrote: > On Wed, 14 Aug 2002, Bruce Momjian wrote: > > > Marc G. Fournier wrote: > > > > They are moving pgaccess more into the admin role, and pgmonitor fit in > > > > with that. > > > > > > Personally, I kinda like to be able to run admin modularized ... they > > > *should* be looking at stuff like webmin, where you can plug-n-play admin > > > functions as required, or horde (http://www.horde.org) ... or http://jfontain.free.fr/moodss/index.html > > > why would I > > > install pgaccess if all I want to do is monitor? Now, to be able to > > > install pgaccess and have pgmonitor tie into *that* would be cool ... > > > > > > 'bigger is better' is MicroSloth's philosophy ... sounds like the PgAccess > > > guys are adopting it too? :( > > > > I assume pgmonitor will just be a new tab in the pgaccess window. It is > > integrated only in that it is part of the tcl scripts supplied. > > Right, but, if its 'integrated', then I have to download the whole thing > ... I only want pgmonitor, so how can I get that now? > > Again, if they do it *properly*, it should be a seperate module you can > download, enable in a config file for pgaccess and have show up ... but it > should be runnable standalone, with all the extras ... > Ok, this is a little off topic for this thread, but maybe I can clear this up really quick, so things can move on. We wanted to have capabilities that PGMonitor provides, in PGAccess. So, we asked Bruce if we could just integrate PGMonitor, and he said yes. To me, it makes sense. Of course you can argue forever on which is better: one big app that contains all the functionality, or several small apps that spread the functionality (ala unix utils). You will get valid arguments on both sides...it is more of a preference thing I believe. Currently, I am integrating it into PGAccess, and I did have to make some modifications for it to work (sorry Bruce...not too many though). However, it is my intention to make this more of a plugin, and also be able to run standalone. So, if you *don't* want PGMonitor, then you don't have to have it, but you will also be able to call PGMonitor by itself (I really haven't decided on a best method yet). So, to answer your question, in the future, you will be able to use PGMonitor standalone. I assumed this from the beginning, since existing users of PGMonitor may not want to use PGAccess (like yourself). --brett > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) -- Brett Schwarz brett_schwarz AT yahoo.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] Open 7.3 items
On Wed, 14 Aug 2002, Lamar Owen wrote: > On Wednesday 14 August 2002 03:29 pm, Vince Vielhaber wrote: > > Hate to complicate things more, but back to a global username, say > > you have user "lowen" that should have access to all databases. What > > happens if there's already a lowen@somedb that's an unprivileged user. > > Assuming lowen is a db superuser, what happens in somedb? If there's > > a global user "lowen" and you try to create a lowen@somedb later, will > > it be allowed? > > If the user 'lowen' is then expanded to 'lowen@template1' it would be stored > that way -- and lowen@template1 is different from lowen@pari, for instance. > The lowen@template1 user could be a superuser and lowen@pari might not -- but > they become distinct users. Although I do understand the difficulty if the > FQDU isn't stored in full in the appropriate places. So I guess the solution > is that wherever a user name is to be stored, the fully qualified form must > be used and checked against, with @template1 being a 'this user is > everywhere' shorthand. > > But maybe I'm just misunderstanding the implementation. I may be too, but what's wrong with just "lowen" being shorthand for 'this user is everywhere'? Does it also mean that we'd have a user postgres@template1? 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] journaling in contrib ...
Marc G. Fournier wrote: > On Wed, 14 Aug 2002, Bruce Momjian wrote: > > > Marc G. Fournier wrote: > > > > They are moving pgaccess more into the admin role, and pgmonitor fit in > > > > with that. > > > > > > Personally, I kinda like to be able to run admin modularized ... they > > > *should* be looking at stuff like webmin, where you can plug-n-play admin > > > functions as required, or horde (http://www.horde.org) ... why would I > > > install pgaccess if all I want to do is monitor? Now, to be able to > > > install pgaccess and have pgmonitor tie into *that* would be cool ... > > > > > > 'bigger is better' is MicroSloth's philosophy ... sounds like the PgAccess > > > guys are adopting it too? :( > > > > I assume pgmonitor will just be a new tab in the pgaccess window. It is > > integrated only in that it is part of the tcl scripts supplied. > > Right, but, if its 'integrated', then I have to download the whole thing > ... I only want pgmonitor, so how can I get that now? > > Again, if they do it *properly*, it should be a seperate module you can > download, enable in a config file for pgaccess and have show up ... but it > should be runnable standalone, with all the extras ... My guess is that it will be integrated and not stand-alone, though tcl apps are so small, you may never notice. -- 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] Open 7.3 items
Lamar Owen wrote: > On Wednesday 14 August 2002 03:29 pm, Vince Vielhaber wrote: > > Hate to complicate things more, but back to a global username, say > > you have user "lowen" that should have access to all databases. What > > happens if there's already a lowen@somedb that's an unprivileged user. > > Assuming lowen is a db superuser, what happens in somedb? If there's > > a global user "lowen" and you try to create a lowen@somedb later, will > > it be allowed? > > If the user 'lowen' is then expanded to 'lowen@template1' it would be stored > that way -- and lowen@template1 is different from lowen@pari, for instance. > The lowen@template1 user could be a superuser and lowen@pari might not -- but > they become distinct users. Although I do understand the difficulty if the > FQDU isn't stored in full in the appropriate places. So I guess the solution > is that wherever a user name is to be stored, the fully qualified form must > be used and checked against, with @template1 being a 'this user is > everywhere' shorthand. Yes, Vince is on to something with his quote above. If we have users with and without @, we get into the situation where users without @ may become users with @ when their usernames collide with existing user/db combinations already created. The point is that those two namespaces do collide and will cause confusion. Then you start to get into the situation where you always add @ and make @template1 a special case. However, remember that this flag can be turned on and off after initdb, so you need to be able to get in to set things up without great complexity _and_ the @template1 would not be passed in from the client, if for no other reason that the username is only 32 characters. It is the backend doing the flagging, and therefore the user can't say 'I am dave@templatge1' vs 'I am dave@connectdb'. This is how I got to the installuser hack in the first place. In fact, even the install user, typically 'postgres' has a problem because if you create 'postgres@db1', 'postgres' will have trouble connecing to db1 as themselves. I think we can live with one user who is special/global, but not more than one because of the confusion it would create. I can change the way this works, but we need a solution without holes. -- 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] journaling in contrib ...
On Wed, 14 Aug 2002, Bruce Momjian wrote: > Marc G. Fournier wrote: > > > They are moving pgaccess more into the admin role, and pgmonitor fit in > > > with that. > > > > Personally, I kinda like to be able to run admin modularized ... they > > *should* be looking at stuff like webmin, where you can plug-n-play admin > > functions as required, or horde (http://www.horde.org) ... why would I > > install pgaccess if all I want to do is monitor? Now, to be able to > > install pgaccess and have pgmonitor tie into *that* would be cool ... > > > > 'bigger is better' is MicroSloth's philosophy ... sounds like the PgAccess > > guys are adopting it too? :( > > I assume pgmonitor will just be a new tab in the pgaccess window. It is > integrated only in that it is part of the tcl scripts supplied. Right, but, if its 'integrated', then I have to download the whole thing ... I only want pgmonitor, so how can I get that now? Again, if they do it *properly*, it should be a seperate module you can download, enable in a config file for pgaccess and have show up ... but it should be runnable standalone, with all the extras ... ---(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
On Wednesday 14 August 2002 03:29 pm, Vince Vielhaber wrote: > Hate to complicate things more, but back to a global username, say > you have user "lowen" that should have access to all databases. What > happens if there's already a lowen@somedb that's an unprivileged user. > Assuming lowen is a db superuser, what happens in somedb? If there's > a global user "lowen" and you try to create a lowen@somedb later, will > it be allowed? If the user 'lowen' is then expanded to 'lowen@template1' it would be stored that way -- and lowen@template1 is different from lowen@pari, for instance. The lowen@template1 user could be a superuser and lowen@pari might not -- but they become distinct users. Although I do understand the difficulty if the FQDU isn't stored in full in the appropriate places. So I guess the solution is that wherever a user name is to be stored, the fully qualified form must be used and checked against, with @template1 being a 'this user is everywhere' shorthand. But maybe I'm just misunderstanding the implementation. -- 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] journaling in contrib ...
Marc G. Fournier wrote: > > They are moving pgaccess more into the admin role, and pgmonitor fit in > > with that. > > Personally, I kinda like to be able to run admin modularized ... they > *should* be looking at stuff like webmin, where you can plug-n-play admin > functions as required, or horde (http://www.horde.org) ... why would I > install pgaccess if all I want to do is monitor? Now, to be able to > install pgaccess and have pgmonitor tie into *that* would be cool ... > > 'bigger is better' is MicroSloth's philosophy ... sounds like the PgAccess > guys are adopting it too? :( I assume pgmonitor will just be a new tab in the pgaccess window. It is integrated only in that it is part of the tcl scripts supplied. -- 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
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Problem is that pg_shadow flat file _only_ has users with passwords. I > > do a btree search of that file, but I am not sure I want to add a dump > > of _all_ users just to allow this. Do we? > > Why not? Doesn't seem like a big penalty ... Well, in most cases pg_pwd doesn't even get created unless someone has a password. We would be creating that file in all cases, or at least in all cases wher db_user_namespace is set, and again, that is a SIGHUP param, so you would need to make sure pg_pwd has the right contents if it was enabled during a sighup. Frankly, I would recommend a new file that just contains user names and is always created. We are basically heading down the road to complexity here. In fact, pg_hba.conf is just a microcosm of how we are going to handle pg_shadow matching. If we create dave@db1, then when dave tries to connect to db1, he comes in as dave@db1, but when he goes to connect to db2, if there is a plain 'dave', he will connect as 'dave' to db2, if possible. If people are OK with that, then I can easily push the double-testing down into the authentication system. It merely means testing the new pg_hba.conf USER column for two values, and pg_shadow for two values, but I would test with @db first. The double testing just seems strange to me because it splits the user namespace into two parts one with @ and one without, and conflicting user parts in the two namespaces do interact when @db does not match. That seems strange, but hey, if no one else thinks it is strange, it is easy to code. It is basically the same as testing pg_pwd, just doing it later in the code. -- 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] Open 7.3 items
On Wednesday 14 August 2002 03:04 pm, Tom Lane wrote: > Lamar Owen <[EMAIL PROTECTED]> writes: > > Appending '@template1' to unadorned usernames, and giving inherited > > rights across the installation to users with template1 rights? Then you > > have the unadorned 'lowen' becomes 'lowen@template1' -- but lowen@pari > > wouldn't have access to template1, right? > If not, standard things like "psql -l" won't work for lowen@pari. I don't > think we can get away with a scheme that depends on disallowing access > to template1 for most people. Ok, maybe I'm really off base, but if I connect to database pari as lowen@pari, isn't pg_database present there? I just tried here: createdb pari psql pari Welcome to psql, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit pari=# select datname from pg_database; datname acs-test maillabels testing2 template1 template0 pari (6 rows) So AFAICT if I were psql I would parse the unadorned lowen as 'lowen@template1' and connect to template1 if not otherwise specified. If the fully qualified database user (FQDU) is present, parse the database name out and connect to that database, then issue the SQL to do the -l or whatever. The @pari would just override the normal default of template1, right? So a 'psql -U lowen@pari -l ' would connect to database pari (subject to permissions) and select datname from pg_database there. What else am I missing, Tom? ISTM I don't need access to template1 -- although I wasn't necessarily suggesting eliminating that. I was more suggesting: lowen@pari has read access to those parts of template1 necessary for normal functioning, full access (subject ot GRANT/REVOKE) of pari, and no access to other databases; lowen@template1 has access across the install (subject to GRANT/REVOKE, of course). lowen@template1 = lowen (unadorned). That was the answer, I thought, to the question Bruce had. There would be NO unadorned usernames then, and no special handling EXCEPT of the template1 database, which is already a special case. Now, can we support the idea of 'postgres@pari' being a superuser for pari but not for the rest of the install? Meaning no CREATE DATABASE right, as that would require write access to template1? That's OK I believe, as I would assume a 'tied to a database' superuser shouldn't be allowed to create a new database to which he isn't going to have access. The full ramifications of this structure could prove interesting. The supersuperuser 'postgres' becomes postgres@template1 -- template1 becoming the consistent default database (for connecting as well as user membership). As anything added to template1 becomes part of any subsequently added databases, being a user in template1 becomes an installation-wide user. And the user never really has to explicitly state @template1 -- they could just leave off the @template1 and everything works as it does now. Yes, there are complications, but not great ones, no? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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
On Wed, 14 Aug 2002, Tom Lane wrote: > Lamar Owen <[EMAIL PROTECTED]> writes: > > Appending '@template1' to unadorned usernames, and giving inherited rights > > across the installation to users with template1 rights? Then you have the > > unadorned 'lowen' becomes 'lowen@template1' -- but lowen@pari wouldn't have > > access to template1, right? > > If not, standard things like "psql -l" won't work for lowen@pari. I don't > think we can get away with a scheme that depends on disallowing access > to template1 for most people. > > It should also be noted that the whole point of this little project was > to do something *simple* ... checking access to some other database to > decide what we will allow is getting a bit far afield from simple. Hate to complicate things more, but back to a global username, say you have user "lowen" that should have access to all databases. What happens if there's already a lowen@somedb that's an unprivileged user. Assuming lowen is a db superuser, what happens in somedb? If there's a global user "lowen" and you try to create a lowen@somedb later, will it be allowed? One possible simplification would be to make the username the full username "lowen@somedb", "lowen", ... Right now we can create a "lowen@somedb" and it's a different user than "lowen" and we can already restrict a user to one database, can't we? Hmmm. Just checked and I guess not - I thought we had a record type of "user". 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] journaling in contrib ...
On Wed, 14 Aug 2002, Bruce Momjian wrote: > Marc G. Fournier wrote: > > On Wed, 14 Aug 2002, Bruce Momjian wrote: > > > > > Marc G. Fournier wrote: > > > > Anything in contrib that can be built seperately from the server code, > > > > that just requires libpq and headers, should be pulled and distributed as > > > > seperate modules, which has the added benefit that, if listed on GBorg, > > > > search engines will pick up the modules ... > > > > > > > > And the whole arg that someone threw out about 'nobody maintaining them if > > > > they aren't part of the distribution' ... so? if nobody is maintaining, > > > > then who is using?? > > > > > > Want to hear something funny? They are moving my pgmonitor off gborg > > > and into the pgaccess. When the move is final, I will add a link on > > > that gborg page. > > > > Ah, so now if I want to use pgmonitor, I have to use pgaccess? guess that > > is one way to sell pgaccess to the masses *shrug* > > They are moving pgaccess more into the admin role, and pgmonitor fit in > with that. Personally, I kinda like to be able to run admin modularized ... they *should* be looking at stuff like webmin, where you can plug-n-play admin functions as required, or horde (http://www.horde.org) ... why would I install pgaccess if all I want to do is monitor? Now, to be able to install pgaccess and have pgmonitor tie into *that* would be cool ... 'bigger is better' is MicroSloth's philosophy ... sounds like the PgAccess guys are adopting it too? :( ---(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
Bruce Momjian <[EMAIL PROTECTED]> writes: > Problem is that pg_shadow flat file _only_ has users with passwords. I > do a btree search of that file, but I am not sure I want to add a dump > of _all_ users just to allow this. Do we? Why not? Doesn't seem like a big penalty ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 items
Lamar Owen <[EMAIL PROTECTED]> writes: > Appending '@template1' to unadorned usernames, and giving inherited rights > across the installation to users with template1 rights? Then you have the > unadorned 'lowen' becomes 'lowen@template1' -- but lowen@pari wouldn't have > access to template1, right? If not, standard things like "psql -l" won't work for lowen@pari. I don't think we can get away with a scheme that depends on disallowing access to template1 for most people. It should also be noted that the whole point of this little project was to do something *simple* ... checking access to some other database to decide what we will allow is getting a bit far afield from simple. 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] journaling in contrib ...
Marc G. Fournier wrote: > On Wed, 14 Aug 2002, Bruce Momjian wrote: > > > Marc G. Fournier wrote: > > > Anything in contrib that can be built seperately from the server code, > > > that just requires libpq and headers, should be pulled and distributed as > > > seperate modules, which has the added benefit that, if listed on GBorg, > > > search engines will pick up the modules ... > > > > > > And the whole arg that someone threw out about 'nobody maintaining them if > > > they aren't part of the distribution' ... so? if nobody is maintaining, > > > then who is using?? > > > > Want to hear something funny? They are moving my pgmonitor off gborg > > and into the pgaccess. When the move is final, I will add a link on > > that gborg page. > > Ah, so now if I want to use pgmonitor, I have to use pgaccess? guess that > is one way to sell pgaccess to the masses *shrug* They are moving pgaccess more into the admin role, and pgmonitor fit in with 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] journaling in contrib ...
On Wed, 14 Aug 2002, Bruce Momjian wrote: > Marc G. Fournier wrote: > > Anything in contrib that can be built seperately from the server code, > > that just requires libpq and headers, should be pulled and distributed as > > seperate modules, which has the added benefit that, if listed on GBorg, > > search engines will pick up the modules ... > > > > And the whole arg that someone threw out about 'nobody maintaining them if > > they aren't part of the distribution' ... so? if nobody is maintaining, > > then who is using?? > > Want to hear something funny? They are moving my pgmonitor off gborg > and into the pgaccess. When the move is final, I will add a link on > that gborg page. Ah, so now if I want to use pgmonitor, I have to use pgaccess? guess that is one way to sell pgaccess to the masses *shrug* ---(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
On Wednesday 14 August 2002 02:38 pm, Bruce Momjian wrote: > Tom Lane wrote: > > The nice thing about it is you can have any combination of people with > > installation-wide access (create them as joeblow) and people with > > one-database access (create them as joeblow@joesdatabase). A special > > case for only the postgres user is much less flexible. > > Also, if you do it this way then the substitution only has to be done in > > one place: you can pass down the correct form to the backend, which'd > > otherwise have to repeat the test to see which username is found. > Yes, certainly a big win. What we _could_ do is to allow connections to > template1 be unsuffixed by the dbname, but that makes everyone > connecting to template1 have problems, and just seemed too weird. > Ideas? Appending '@template1' to unadorned usernames, and giving inherited rights across the installation to users with template1 rights? Then you have the unadorned 'lowen' becomes 'lowen@template1' -- but lowen@pari wouldn't have access to template1, right? Or am I misunderstanding the feature? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] More CVS Problems
I have been getting this for at least two days: [matthew@zeut src]$ cvs -v Concurrent Versions System (CVS) 1.11.2 (client/server) [matthew@zeut src]$ cvs -z3 -d :pserver:[EMAIL PROTECTED]:/projects/cvsroot co -P pgsql [...] cvs server: Updating pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic cvs server: failed to create lock directory for `/projects/cvsroot/pgsql-server/src/backend/utils/mb/conversion_procs/ascii_and_mic' (/projects/cvsroot/pgsql-server/src/backend/utils/mb/conversion_procs/ascii_and_mic/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository `/projects/cvsroot/pgsql-server/src/backend/utils/mb/conversion_procs/ascii_and_mic' cvs [server aborted]: read lock failed - giving up ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 items
On Wed, 2002-08-14 at 14:34, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Oh, so try it with and without. I can do that, but it seems more of a > > security problem where you were trying two names instead of one. Do > > people like that? > > The nice thing about it is you can have any combination of people with > installation-wide access (create them as joeblow) and people with > one-database access (create them as joeblow@joesdatabase). A special > case for only the postgres user is much less flexible. > > > It is easy to do, except for the fact we have to > > match pg_hba.conf with a username, though we could do the double-test > > there too, if that isn't too weird. > > It'd probably be better to first look at the flat-file copy of pg_shadow > to determine whether user or user@database is the form to use, and then > run through pg_hba.conf only once using the correct form. Otherwise > there are going to be all sorts of weird corner cases: user might match > a different pg_hba row than user@database does. > > Also, if you do it this way then the substitution only has to be done in > one place: you can pass down the correct form to the backend, which'd > otherwise have to repeat the test to see which username is found. If there is a global 'user', then a database specific 'user@database' should be rejected shouldn't it? Otherwise we wind up with two potential 'user@database' users (globals users are really user@) but with a single ID. ---(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
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Oh, so try it with and without. I can do that, but it seems more of a > > security problem where you were trying two names instead of one. Do > > people like that? > > The nice thing about it is you can have any combination of people with > installation-wide access (create them as joeblow) and people with > one-database access (create them as joeblow@joesdatabase). A special > case for only the postgres user is much less flexible. Oh, yes, clearly a nice addition, but see below. > > It is easy to do, except for the fact we have to > > match pg_hba.conf with a username, though we could do the double-test > > there too, if that isn't too weird. > > It'd probably be better to first look at the flat-file copy of pg_shadow > to determine whether user or user@database is the form to use, and then > run through pg_hba.conf only once using the correct form. Otherwise > there are going to be all sorts of weird corner cases: user might match > a different pg_hba row than user@database does. Problem is that pg_shadow flat file _only_ has users with passwords. I do a btree search of that file, but I am not sure I want to add a dump of _all_ users just to allow this. Do we? > Also, if you do it this way then the substitution only has to be done in > one place: you can pass down the correct form to the backend, which'd > otherwise have to repeat the test to see which username is found. Yes, certainly a big win. What we _could_ do is to allow connections to template1 be unsuffixed by the dbname, but that makes everyone connecting to template1 have problems, and just seemed too weird. Ideas? -- 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] Open 7.3 items
Bruce Momjian <[EMAIL PROTECTED]> writes: > Oh, so try it with and without. I can do that, but it seems more of a > security problem where you were trying two names instead of one. Do > people like that? The nice thing about it is you can have any combination of people with installation-wide access (create them as joeblow) and people with one-database access (create them as joeblow@joesdatabase). A special case for only the postgres user is much less flexible. > It is easy to do, except for the fact we have to > match pg_hba.conf with a username, though we could do the double-test > there too, if that isn't too weird. It'd probably be better to first look at the flat-file copy of pg_shadow to determine whether user or user@database is the form to use, and then run through pg_hba.conf only once using the correct form. Otherwise there are going to be all sorts of weird corner cases: user might match a different pg_hba row than user@database does. Also, if you do it this way then the substitution only has to be done in one place: you can pass down the correct form to the backend, which'd otherwise have to repeat the test to see which username is found. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 items
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > In a way that user has to be special for this case > > because of the requirement that at least one person be able to connect > > when you flip that flag. > > Why does anyone need to be special? The behavior should be to try the > given user name, and if that's not found then to try user@db. I see no > need to special-case any user. Oh, so try it with and without. I can do that, but it seems more of a security problem where you were trying two names instead of one. Do people like that? It is easy to do, except for the fact we have to match pg_hba.conf with a username, though we could do the double-test there too, if that isn't too weird. > > Basically, I am not going to stop working on something when one person > > objects or this will never get done, > > He didn't say to stop working on it. He said to fix the misdesigned > parts. And I quite agree that those parts are misdesigned. I will fix them as long as the fixes don't generate new objections, like adding a new column to pg_shadow. -- 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] pg_dump output portability
Peter Eisentraut wrote: > I needed to move a PostgreSQL database to another product but I noticed ^^ Surely this is a misprint. ;-) > that the pg_dump output contains a few artifacts that make the output > nonportable. Most of these should be relatively easy to fix. Here's my > list: Maybe we need a "maximum portability" flag for pg_dump that will do some of the things outlined below. -- 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] pg_dump output portability
> * Is anyone working on using standard foreign key creation commands > instead of CREATE CONSTRAINT TRIGGER? Submitted with the pg_constraint patch, and more recently updated to match cvs tip. I believe Tom wishes to review this prior to application. ---(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] journaling in contrib ...
Marc G. Fournier wrote: > Anything in contrib that can be built seperately from the server code, > that just requires libpq and headers, should be pulled and distributed as > seperate modules, which has the added benefit that, if listed on GBorg, > search engines will pick up the modules ... > > And the whole arg that someone threw out about 'nobody maintaining them if > they aren't part of the distribution' ... so? if nobody is maintaining, > then who is using?? Want to hear something funny? They are moving my pgmonitor off gborg and into the pgaccess. When the move is final, I will add a link on that gborg page. -- 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
I believe the dictionary meaning of 'object' in this context would be 'a cause for concern or attention'. Each of Peters uses of the word is highly appropriate, as he was concerned and I'd agree with the sentiments that those concepts needed attention. Anyway, object with stars and strongly object are definitely leaning towards abuse of the word. On Wed, 2002-08-14 at 13:35, Bruce Momjian wrote: > > This email brings up another issue I have seen recently. The use of the > word "object", "strongly object", or "*object*" with stars is a very > > > I had to add to initdb to create a file /data/PG_INSTALLER and have the > > > postmaster read that on startup to determine the installing user. > > > > I object to treating one user specially. There should be a general > > mechanism, such as a separate column in pg_shadow. > > > > I also object to fixing the name during initdb. We just got rid of that > > requirement. > > > > If it mattered, I would also object to the choice of the file name. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] journaling in contrib ...
Tom Lane wrote: > I'd suggest dropping the talk slides (and you might as well flatten the > thing into one directory). Perhaps instead the README could include a > pointer to where to find the talk slides on-line. That'd bring it down > to half a dozen K which is a more appropriate size for a contrib item > (and hopefully will not trigger Marc's wrath ;-)). OK, we got _that_ answer. Looks like gborg. Marc really wants to pump that up. -- 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
Bruce Momjian <[EMAIL PROTECTED]> writes: > In a way that user has to be special for this case > because of the requirement that at least one person be able to connect > when you flip that flag. Why does anyone need to be special? The behavior should be to try the given user name, and if that's not found then to try user@db. I see no need to special-case any user. > Basically, I am not going to stop working on something when one person > objects or this will never get done, He didn't say to stop working on it. He said to fix the misdesigned parts. And I quite agree that those parts are misdesigned. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] pg_dump output portability
Peter Eisentraut <[EMAIL PROTECTED]> writes: > I needed to move a PostgreSQL database to another product but I noticed > that the pg_dump output contains a few artifacts that make the output > nonportable. Most of these should be relatively easy to fix. Most of these look like they would break a lot of people --- for example, we can't just arbitrarily change the results of bool_out. > * Identifier quoting seems to be inconsistent. The -n option gives you > portable behaviour (quoted only if mixed case or funny characters), but > the default -N doesn't actually quote some things that are generated by > the backend, including rule and index creation commands. Is there a point > in having the -n behavior at all? You mean you'd rather eliminate the -N behavior, no? I'd vote for that. > * Nonprintable characters in string literals are currently output as octal > escape sequences (e.g., \012). It would be more portable to just print > out the characters as is. This should be an option -- any opinions on > which might be a better default? Again, I'm fairly suspicious of this; it seems likely to result in failures to read in the data. You can't just leave data newlines as-is for example. > * The expression reverse-engineering code outputs ::text and similar casts > in many cases. These should be CAST(). I will vote against this as being a major loss of legibility. Perhaps we could compromise on controlling it by a GUC variable, though. > * It was once proposed to make SET SESSION AUTHORIZATION the default in > pg_dump. What became of that? I think this is a good idea, and was meaning to do it but hadn't got round to it. > * Is anyone working on using standard foreign key creation commands > instead of CREATE CONSTRAINT TRIGGER? Rod Taylor submitted a patch for that, which I was planning to review and apply shortly. 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] CLUSTER all tables at once?
Sounds good to me. TODO updated: o Cluster all tables at once using pg_index.indisclustered set during previous CLUSTER --- Zeugswetter Andreas SB SD wrote: > > > Added to TODO: > > > > o Cluster all tables at once using pg_index.indisclustered or primary key > > > > > > And what happens with those tables that do not have any such index? > > > > > > Nothing, would be my vote. You'd just re-CLUSTER all tables that have > > > been clustered before, the same way they were last clustered. > > I second Tom's opinion. If the table was not clustered before leave it as is. > > Thus the TODO should imho (if at all :-) read: > o Cluster all tables at once that have a pg_index.indisclustered > > Andreas > > ---(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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Domains and Indexes
Thanks. I will keep it in the queue for CVS commit message sake. --- Rod Taylor wrote: > Sorry Bruce, this was included as a part of the patch of the below > subject: > > Re: [PATCHES] Dump serials as serial -- not a sequence > > > Patch may be smart enough to say 'already applied'. > > > On Wed, 2002-08-14 at 01:29, Bruce Momjian wrote: > > > > 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. > > > > --- > > > > > > Rod Taylor wrote: > > > Appears there is a problem finding the opclass when indexing a domain. > > > > > > CREATE DOMAIN newint as int4; > > > CREATE TABLE tab (col newint unique); > > > ERROR: data type newint has no default operator class for access method > > > "btree" > > > You must specify an operator class for the index or define a > > > default operator class for the data type > > > > > > > > > Specifically, GetDefaultOpClass() finds 0 exact matches and 3 binary > > > compatible matches. Fetching getBaseType() of the attribute fixes the > > > problem for domains (see attachment). > > > > > > However, I have to wonder why GetDefaultOpClass doesn't simply use the > > > first Binary Compatible opclass. When there is more than one usable it > > > doesn't do anything useful. > > > > > > > > > > [ Attachment, skipping... ] > > > > > > > > ---(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 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
