[HACKERS] [pgsql-hackers-owner+M6959@postgresql.org: Majordomo Delivery Error]
I think somebody has the "owner" address forwarding to the list. Really annoying. Would somebody please stop that? Thanks, -Roberto - Forwarded message from [EMAIL PROTECTED] - From: [EMAIL PROTECTED] Subject: Majordomo Delivery Error To: [EMAIL PROTECTED] X-VMS-To: IN%"[EMAIL PROTECTED]" This message was created automatically by mail delivery software. A Majordomo message could not be delivered to the following addresses: [EMAIL PROTECTED]: 450 4.7.1 <[EMAIL PROTECTED]>... Can not check MX records for recipient host htmlhost.net -- Original message omitted -- - End forwarded message - -- +| http://fslc.usu.edu USU Free Software & GNU/Linux Club|--+ Roberto Mello - Computer Science, USU - http://www.brasileiro.net http://www.sdl.usu.edu - Space Dynamics Lab, Developer A seminar on Time Travel will be held two weeks ago ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Changing the default value of an inherited column
At 21:00 31/03/01 -0500, Tom Lane wrote: > >If we change the code again based on the latest discussion, then pg_dump >would have to detect whether there are conflicting defaults, which would >mean looking at all the parents not just the rightmost one. Ugh. That >might be a good reason not to change... > Shall I hold off on this for a day or two to let the other discussion settle down? It seems whatever happens, we should check NOT NULL. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Complete Database Permission
Hi Everybody: How can i set permission for any user (in a database) in the entire database (all tables) ??? with GRANT is just one table (or list), but i want , for example, create a user and set his permissions in all tables , but just SELECT for example, (without set superuser or createdb , etc)... Thanks
Re: [HACKERS] Re: Changing the default value of an inherited column
At 20:25 31/03/01 -0500, Tom Lane wrote: > >> That's what I meant; can we easily do the 'not in the parent' part, since >> we may have to go up a long hierarchy to find the parent? > >pg_dump must already contain code to traverse the inheritance hierarchy >(I haven't looked to see where). Couldn't we just extend it to believe >that it's found a match only if the default value and NOT NULL state >match, as well as the column name? > You are correct; flagInhAttrs in common.c does the work, and it should be easy to change. At the moment it extracts all tables attrs then looks for an attr with the same name in any parent table. We can extend this to check NOT NULL and DEFAULT. Should I also check TYPEDEFN - can that be changed? Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(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] Re: Changing the default value of an inherited column
On Fri, Mar 30, 2001 at 12:10:59PM -0500, Tom Lane wrote: > Comments? I'm going to implement and commit this today unless I hear > loud squawks ... I like it in general and I think it opens some interesting possibilities. I don't know much about how the inheritance system is implemented, so I will put out this scenario in case it makes a difference. We recently decided to refactor our schema a bit, using inheritance. All of our tables have a primary key called "seq" along with some other common fields such as entry time, etc. We realized that moving them into a "base" table allowed us to create functions on "base" that would work on every derived table. The main problem was that we needed fields like "seq" to have distinct sequences, which was not possible without the ability to override the default value in each derived table. It seems like this would be easily doable with this change. Another thing that seems kind of interesting would be to have: CREATE TABLE base (table_id CHAR(8) NOT NULL [, etc.]); CREATE TABLE foo (table_id CHAR(8) NOT NULL DEFAULT 'foo'); CREATE TABLE bar (table_id CHAR(8) NOT NULL DEFAULT 'foo'); Then a function on "base" could look at table_id and know which table it's working on. A waste of space, but I can think of uses for it. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] MacOS X OK, was: Call for platforms
Well, once I figured out a few things about how to use the Unix part of MacOS X it seemed to work without a hitch in the regression testing. I need to figure out how to make the system start it up automatically at boot time still, but then I need to figure out how to do double sided printing on an HP 5si and several other things too. Printout at end. Details available if needed. BTW the offer of testing on NetBSD/mac68k stands. 250MB is plenty if you don't use X, and I have some extra disks anyway. I'll probably try NetBSD/macppc sometime in the next week or so. >At 5:14 PM + 3/26/01, Thomas Lockhart wrote: >>NetBSD m68k7.0 2000-04-10, Henry B. Hotz > >I no longer have a 68k machine that's fast enough to reasonably test >PG on. I have a IIcx that sometimes serves as a router, but I'm >using some second-generation powermac's mostly now. (You still >have that Centris in your closet Tom?) > >I *did* just get MacOS X this weekend though and if I get it working >on my work G4 maybe I could give it a try there. Screen output from regression test. >[localhost:src/test/regress] hotz%make check >sed -e 's,@bindir@,/usr/local/pgsql/bin,g' \ >-e 's,@libdir@,/usr/local/pgsql/lib,g' \ >-e 's,@datadir@,/usr/local/pgsql/share,g' \ >-e 's/@VERSION@/7.1RC1/g' \ >-e 's/@host_tuple@/powerpc-apple-darwin1.3/g' \ >-e 's,@GMAKE@,make,g' \ >-e 's/@enable_shared@/yes/g' \ >-e 's/@GCC@/yes/g' \ > pg_regress.sh >pg_regress >chmod a+x pg_regress >cc -traditional-cpp -g -O2 -Wall -Wmissing-prototypes >-Wmissing-declarations -bundle -undefined suppress >-I../../../src/interfaces/libpq -I../../../src/include -c -o >regress.o regress.c >cc -traditional-cpp -g -O2 -Wall -Wmissing-prototypes >-Wmissing-declarations -bundle -undefined suppress -bundle >-undefined suppress -o regress.so regress.o >sed -e >'s,@abs_srcdir@,/Users/hotz/dist/postgresql-7.1RC1/src/test/regress,g' >-e >'s,@abs_builddir@,/Users/hotz/dist/postgresql-7.1RC1/src/test/regress, >g' -e 's/@DLSUFFIX@/.so/g' input/copy.source >sql/copy.sql >sed -e >'s,@abs_srcdir@,/Users/hotz/dist/postgresql-7.1RC1/src/test/regress,g' >-e >'s,@abs_builddir@,/Users/hotz/dist/postgresql-7.1RC1/src/test/regress, >g' -e 's/@DLSUFFIX@/.so/g' >input/create_function_1.source >sql/create_function_1.sql >sed -e >'s,@abs_srcdir@,/Users/hotz/dist/postgresql-7.1RC1/src/test/regress,g' >-e >'s,@abs_builddir@,/Users/hotz/dist/postgresql-7.1RC1/src/test/regress, >g' -e 's/@DLSUFFIX@/.so/g' >input/create_function_2.source >sql/create_function_2.sql >sed -e >'s,@abs_srcdir@,/Users/hotz/dist/postgresql-7.1RC1/src/test/regress,g' >-e >'s,@abs_builddir@,/Users/hotz/dist/postgresql-7.1RC1/src/test/regress, >g' -e 's/@DLSUFFIX@/.so/g' input/misc.source >sql/misc.sql >sed -e >'s,@abs_srcdir@,/Users/hotz/dist/postgresql-7.1RC1/src/test/regress,g' >-e >'s,@abs_builddir@,/Users/hotz/dist/postgresql-7.1RC1/src/test/regress, >g' -e 's/@DLSUFFIX@/.so/g' >input/constraints.source >sql/constraints.sql >sed -e >'s,@abs_srcdir@,/Users/hotz/dist/postgresql-7.1RC1/src/test/regress,g' >-e >'s,@abs_builddir@,/Users/hotz/dist/postgresql-7.1RC1/src/test/regress, >g' -e 's/@DLSUFFIX@/.so/g' output/copy.source >expected/copy.out >sed -e >'s,@abs_srcdir@,/Users/hotz/dist/postgresql-7.1RC1/src/test/regress,g' >-e >'s,@abs_builddir@,/Users/hotz/dist/postgresql-7.1RC1/src/test/regress, >g' -e 's/@DLSUFFIX@/.so/g' >output/create_function_1.source >expected/create_function_1.out >sed -e >'s,@abs_srcdir@,/Users/hotz/dist/postgresql-7.1RC1/src/test/regress,g' >-e >'s,@abs_builddir@,/Users/hotz/dist/postgresql-7.1RC1/src/test/regress, >g' -e 's/@DLSUFFIX@/.so/g' >output/create_function_2.source >expected/create_function_2.out >sed -e >'s,@abs_srcdir@,/Users/hotz/dist/postgresql-7.1RC1/src/test/regress,g' >-e >'s,@abs_builddir@,/Users/hotz/dist/postgresql-7.1RC1/src/test/regress, >g' -e 's/@DLSUFFIX@/.so/g' output/misc.source >expected/misc.out >sed -e >'s,@abs_srcdir@,/Users/hotz/dist/postgresql-7.1RC1/src/test/regress,g' >-e >'s,@abs_builddir@,/Users/hotz/dist/postgresql-7.1RC1/src/test/regress, >g' -e 's/@DLSUFFIX@/.so/g' >output/constraints.source >expected/constraints.out >make -C ../../../contrib/spi REFINT_VERBOSE=1 refint.so autoinc.so >cc -traditional-cpp -g -O2 -Wall -Wmissing-prototypes >-Wmissing-declarations -bundle -undefined suppress -I. >-I../../src/include -DREFINT_VERBOSE -c -o refint.o refint.c >cc -traditional-cpp -g -O2 -Wall -Wmissing-prototypes >-Wmissing-declarations -bundle -undefined suppress -bundle >-undefined suppress -o refint.so refint.o >cc -traditional-cpp -g -O2 -Wall -Wmissing-prototypes >-Wmissing-declarations -bundle -undefined suppress -I. >-I../../src/include -DREFINT_VERBOSE -c -o autoinc.o autoinc.c >cc -traditional-cpp -g -O2 -Wall -Wmissing-prototypes >-Wmissing-declarations -bundle -undefined suppress -bundle >-undefined suppress -o autoinc.so autoinc.o >rm refint.
Re: [HACKERS] Re: Changing the default value of an inherited column
At 20:40 31/03/01 -0500, Tom Lane wrote: >Philip Warner <[EMAIL PROTECTED]> writes: >> You are correct; flagInhAttrs in common.c does the work, and it should be >> easy to change. At the moment it extracts all tables attrs then looks for >> an attr with the same name in any parent table. We can extend this to check >> NOT NULL and DEFAULT. Should I also check TYPEDEFN - can that be changed? > >We presently disallow change of type in child tables, but you might as >well check that too, if it's just one more strcmp ... Looks like it; and just to confirm, based on previous messages, I assume I should look at the parents from right to left? Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Changing the default value of an inherited column
Philip Warner <[EMAIL PROTECTED]> writes: > Looks like it; and just to confirm, based on previous messages, I assume I > should look at the parents from right to left? At the moment that would be the right thing to do. If we change the code again based on the latest discussion, then pg_dump would have to detect whether there are conflicting defaults, which would mean looking at all the parents not just the rightmost one. Ugh. That might be a good reason not to change... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: [ADMIN] User administration tool
On Fri, Mar 30, 2001 at 10:48:54AM -0500, Bruce Momjian wrote: > > Bruce Momjian writes: > > > > > I have started coding a user/group administration tool that allows you > > > to add/modify/delete users and groups. I should have something working > > > in a week. I will look similar to my pgmonitor tool. > > > > Pgaccess already does part of this. If you're going to write it in Tcl/Tk > > anyway, I think you might as well integrate it there. > > Wow, I see. I never suspected it did that too. :-) Seems I don't need > to write anything, except perhaps add group capabilities to pgaccess. Isn't phpPgAdmin yet another tool of this type? I haven't tried it myself, (no need, myself being the only user...) but the web page (http://www.greatbridge.org/project/phppgadmin/projdisplay.php) says: Features include: * create and drop databases * create, copy, drop and alter tables/views/sequences/functions/indicies/triggers * edit and add fields (to the extent Postgres allows) * execute any SQL-statement, even batch-queries * manage primary and unique keys * create and read dumps of tables * administer one single database * administer multiple servers * administer postgres users and groups Greetinx, Jan -- +- Jan T. Kim ---+ | *NEW* --> email: [EMAIL PROTECTED] | | *NEW* --> WWW: http://www.inb.mu-luebeck.de/staff/kim.html | *-=< hierarchical systems are for files, not for humans >=-* ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Third call for platform testing (linux 2.4.x)
I just built and tested RC1 on Linux 2.4.2, with glibc-2.2.2 and
gcc-2.95.2 on a Debian 2.2+ x86 system. ("+" implying some packages
from "unstable".)
I configured it --with-perl --with-openssl --with-CXX.
It built without errors, but with a few warnings.
This one seemed (portably) odd:
--
In file included from gram.y:43:
lex.plpgsql_yy.c: In function `plpgsql_yylex':
lex.plpgsql_yy.c:972: warning: label `find_rule' defined but not used
--
And this:
--
ar crs libpq.a `lorder fe-auth.o fe-connect.o fe-exec.o fe-misc.o fe-print.o
fe-lobj.o pqexpbuffer.o dllist.o pqsignal.o | tsort`
tsort: -: input contains a loop:
tsort: dllist.o
--
And this:
--
ar crs libecpg.a `lorder execute.o typename.o descriptor.o data.o error.o prepare.o
memory.o connect.o misc.o | tsort`
tsort: -: input contains a loop:
tsort: connect.o
tsort: execute.o
tsort: data.o
--
And this:
--
ar crs libplpgsql.a `lorder pl_parse.o pl_handler.o pl_comp.o pl_exec.o pl_funcs.o |
tsort`
tsort: -: input contains a loop:
tsort: pl_comp.o
tsort: pl_parse.o
--
I ran "make check". It said:
--
All 76 tests passed.
--
Nathan Myers
[EMAIL PROTECTED]
On Sat, Mar 31, 2001 at 12:02:35PM +1200, Franck Martin wrote:
> I still don't see an entry for Linux 2.4.x
>
> Cheers.
>
> Thomas Lockhart wrote:
>
> > Unreported or problem platforms:
> >
> > Linux 2.0.x MIPS 7.0 2000-04-13 (Tatsuo has lost machine)
> > mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii
> > NetBSD m68k7.0 2000-04-10 (Henry has lost machine)
> > NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo
> > QNX 4.25 x86 7.0 2000-04-01, Dr. Andreas Kardos
> > Ultrix MIPS7.1 2001-??-??, Alexander Klimov
> >
> > mklinux has failed Tatsuo's testing afaicr. Demote to unsupported?
> >
> > Any NetBSD partisans who can do testing or solicit testing from the
> > NetBSD crowd? Same for OpenBSD?
> >
> > QNX is known to have problems with 7.1. Any hope of fixing for 7.1.1? Is
> > there anyone able to work on it? If not, I'll move to the unsupported
> > list.
> >
> > And here are the up-to-date platforms; thanks for the reports:
> >
> > AIX 4.3.3 RS6000 7.1 2001-03-21, Gilles Darold
> > BeOS 5.0.3 x86 7.1 2000-12-18, Cyril Velter
> > BSDI 4.01 x86 7.1 2001-03-19, Bruce Momjian
> > Compaq Tru64 4.0g Alpha 7.1 2001-03-19, Brent Verner
> > FreeBSD 4.3 x867.1 2001-03-19, Vince Vielhaber
> > HPUX PA-RISC 7.1 2001-03-19, 10.20 Tom Lane, 11.00 Giles Lean
> > IRIX 6.5.11 MIPS 7.1 2001-03-22, Robert Bruccoleri
> > Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick
> > Linux 2.2.x armv4l 7.1 2001-03-22, Mark Knox
> > Linux 2.2.18 PPC750 7.1 2001-03-19, Tom Lane
> > Linux 2.2.x S/390 7.1 2000-11-17, Neale Ferguson
> > Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick
> > Linux 2.2.16 x86 7.1 2001-03-19, Thomas Lockhart
> > MacOS X Darwin PPC 7.1 2000-12-11, Peter Bierman
> > NetBSD 1.5 alpha 7.1 2001-03-22, Giles Lean
> > NetBSD 1.5E arm32 7.1 2001-03-21, Patrick Welche
> > NetBSD 1.5S x867.1 2001-03-21, Patrick Welche
> > OpenBSD 2.8 x867.1 2001-03-22, Brandon Palmer
> > SCO OpenServer 5 x86 7.1 2001-03-13, Billy Allie
> > SCO UnixWare 7.1.1 x86 7.1 2001-03-19, Larry Rosenman
> > Solaris 2.7 Sparc 7.1 2001-03-22, Marc Fournier
> > Solaris x867.1 2001-03-27, Mathijs Brands
> > SunOS 4.1.4 Sparc 7.1 2001-03-23, Tatsuo Ishii
> > Windows/Win32 x86 7.1 2001-03-26, Magnus Hagander (clients only)
> > WinNT/Cygwin x86 7.1 2001-03-16, Jason Tishler
> >
> > ---(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 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: [SQL] possible row locking bug in 7.0.3 & 7.1
On Thursday 29 March 2001 22:15, Tom Lane wrote: > > Just looked in heapam.c - I can fix it in two hours. > > The question is - should we do this now? > > This scares the hell out of me. > > I do NOT think we should be making quick-hack changes in fundamental > system semantics at this point of the release cycle. Although I'm the one who is being bit by this bug, I tend to agree. > The problem went unnoticed for two full release cycles I first reported the problem on 25 September 2000, on the pgsql-sql list, message subject "SQL functions not locking properly?" I was using 7.0.2 at the time. Also, I seem to remember that a problem of this nature bit me in 6.5.x as well. > it can wait another cycle for a fix that has been considered, reviewed, > and tested. Let's not risk making things worse by releasing a new > behavior we might find out is also wrong. Good point. How long is the next cycle likely to take? Forest ---(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] Re: Changing the default value of an inherited column
Philip Warner <[EMAIL PROTECTED]> writes: > You are correct; flagInhAttrs in common.c does the work, and it should be > easy to change. At the moment it extracts all tables attrs then looks for > an attr with the same name in any parent table. We can extend this to check > NOT NULL and DEFAULT. Should I also check TYPEDEFN - can that be changed? We presently disallow change of type in child tables, but you might as well check that too, if it's just one more strcmp ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Changing the default value of an inherited column
Philip Warner <[EMAIL PROTECTED]> writes: > At 20:02 31/03/01 -0500, Tom Lane wrote: >> Perhaps we should just hack that code >> to not suppress inherited attrs when they have default values and/or >> NOT NULL that's not in the parent. > That's what I meant; can we easily do the 'not in the parent' part, since > we may have to go up a long hierarchy to find the parent? pg_dump must already contain code to traverse the inheritance hierarchy (I haven't looked to see where). Couldn't we just extend it to believe that it's found a match only if the default value and NOT NULL state match, as well as the column name? 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] Re: Changing the default value of an inherited column
At 20:02 31/03/01 -0500, Tom Lane wrote: > >Perhaps we should just hack that code >to not suppress inherited attrs when they have default values and/or >NOT NULL that's not in the parent. That's what I meant; can we easily do the 'not in the parent' part, since we may have to go up a long hierarchy to find the parent? Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Changing the default value of an inherited column
Philip Warner <[EMAIL PROTECTED]> writes: > At 01:36 31/03/01 -0500, Tom Lane wrote: >> which is OK as far as the field set goes, but it loses the additional >> DEFAULT and NOT NULL information for the child table. Any thoughts on >> the best way to fix this? > Can pg_dump easily detect overridden attrs? If so, we just treat them as > table attrs and let the backend do it's stuff. Well, it's already detecting inherited attrs so it can suppress them from the explicit column list. Perhaps we should just hack that code to not suppress inherited attrs when they have default values and/or NOT NULL that's not in the parent. 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] Re: [SQL] Re: pg_dump potential bug -UNIQUE INDEX on PG_SHADOWDont!! HELP
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > First, here is a patch which will prevent this from happening in the
> > future. Do people want this held for 7.2 or applied now? It disables
> > the creation of user indexes on system tables.
>
> > + if (heapRelationName && !allow_system_table_mods &&
> > + IsSystemRelationName(heapRelationName) && IsNormalProcessingMode())
> > + {
> > + elog(ERROR, "You can not create indexes on system tables: '%s'",
> > +heapRelationName);
> > + }
> > +
>
> I think it would be a real good idea to put in this safeguard, but
> I don't much like that error message. How about
>
> elog(ERROR, "User-defined indexes on system catalogs are not supported");
Change made to patch.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
---(end of broadcast)---
TIP 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] Re: [SQL] Re: pg_dump potential bug -UNIQUE INDEX on PG_SHADOW Dont!! HELP
Bruce Momjian <[EMAIL PROTECTED]> writes:
> First, here is a patch which will prevent this from happening in the
> future. Do people want this held for 7.2 or applied now? It disables
> the creation of user indexes on system tables.
> + if (heapRelationName && !allow_system_table_mods &&
> + IsSystemRelationName(heapRelationName) && IsNormalProcessingMode())
> + {
> + elog(ERROR, "You can not create indexes on system tables: '%s'",
> + heapRelationName);
> + }
> +
I think it would be a real good idea to put in this safeguard, but
I don't much like that error message. How about
elog(ERROR, "User-defined indexes on system catalogs are not supported");
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Changing the default value of an inherited column
[EMAIL PROTECTED] (Nathan Myers) writes: >> This seems pretty random. It would be more reasonable if multiple >> (default) inheritance weren't allowed unless you explicitly specify a new >> default for the new column, but we don't have a syntax for this. > I agree, but I thought the original issue was that PG _does_ now have > syntax for it. Any conflict in default values should result in either > a failure, or "no default". Choosing a default randomly, or according > to an arbitrary and complicated rule (same thing), is a source of > bugs. Well, we *do* have a syntax for specifying a new default (the same one that worked pre-7.0 and does now again). I guess what you are proposing is the rule "If conflicting default values are inherited from multiple parents that each define the same column name, then an error is reported unless the child table redeclares the column and specifies a new default to override the inherited ones". That is: create table p1 (f1 int default 1); create table p2 (f1 int default 2); create table c1 (f2 float) inherits(p1, p2); would draw an error about conflicting defaults for c1.f1, but create table c1 (f1 int default 3, f2 float) inherits(p1, p2); would be accepted (and 3 would become the default for c1.f1). This would take a few more lines of code, but I'm willing to do it if people think it's a safer behavior than picking one of the inherited default values. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Changing the default value of an inherited column
[EMAIL PROTECTED] (Nathan Myers) writes: > Of course PG is different from any O-O language. I don't know if PG > has an equivalent to the "base-class context". I suppose PG has a long > history of merging like-named members, and that the issue is just of > the details of how the merge happens. Yes; AFAICT that behavior goes back to PostQUEL. It was partially disabled (without adequate discussion I guess) in 7.0, but it's been around for a long time. >> 4. All relevant constraints from all the column specifications will >> be applied. In particular, if any of the specifications includes NOT >> NULL, the resulting column will be NOT NULL. (But the current >> implementation does not support inheritance of UNIQUE or PRIMARY KEY >> constraints, and I do not have time to add that now.) > Sounds like a TODO item... There's something about it in TODO already. There are some definitional issues though (should uniqueness be across ALL tables of the inheritance hierarchy, or per-table? If the former, how would we implement it?). I believe you can find past discussions about this in the archives. > Do all the triggers of the base tables get applied, to be run one after > another? Triggers aren't inherited either. Possibly they should be, but again I think some forethought is needed... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Re: [SQL] Re: pg_dump potential bug -UNIQUE INDEX on PG_SHADOW Dont!!HELP
Can I get a comment on this patch. Hold for 7.2 or apply?
initdb works with the patch. People who create indexes on global tables
get a failed database, while people who create indexes on non-global
system tables get unreliable indexes. This prevents such index
creation.
I don't know how many people are creating their own system indexes.
> > Hi
> >
> > Regarding my previous post, I just successfully created a unique index on
> > pg_shadow. DON'T DO THIS!!!
> > ---
> > CREATE UNIQUE INDEX shadow_index ON pg_shadow (usename)
> > ---
> > I couldn't create at pg_shadow_index as the pg prefix is reserved for
> > system tables.
> >
> > This BROKE the database. At least I can't connect anymore with a:
> > ---
> > template1=# \c statements
> > FATAL 1: Index 'pg_shadow_name_index' does not exist
> > Previous connection kept
> > template1=#
> > ---
> > If I look at the error log I get :
> > ---
> > ERROR: Illegal class name 'pg_shadow_index'
> > The 'pg_' name prefix is reserved for system catalogs
> > ERROR: Index 'pg_shadow_name_index' does not exist
> > ERROR: SearchSysCache: recursive use of cache 23
> > ERROR: SearchSysCache: recursive use of cache 23
> > ERROR: SearchSysCache: recursive use of cache 23
> > ERROR: SearchSysCache: recursive use of cache 23 <-- quite psql here
> > FATAL 1: Index 'pg_shadow_name_index' does not exist <-- restarted again
> > FATAL 1: Index 'pg_shadow_name_index' does not exist
> > FATAL 1: Index 'pg_shadow_name_index' does not exist
> > ---
> >
> > What can I do??? I've got a non-trivial amount of data that I cannot afford
> > to lose!! HELP!..
>
> First, here is a patch which will prevent this from happening in the
> future. Do people want this held for 7.2 or applied now? It disables
> the creation of user indexes on system tables.
>
> The user-defined indexes on system columns can not be made to work
> easily. Tom Lane pointed out to me in a phone call that code like:
>
> CatalogIndexInsert(irelations, Num_pg_class_indices, relrelation, reltup);
>
> assumes it knows the number of indexes on each system table, and a
> user-defined one would not be updated by any system catalog change that
> did not go through the executor.
>
> As far as recovery, I am not sure. One issue is that pg_shadow is a
> global table, not local to the database. My guess is that the global
> table is still fine, but the index is in the database where you created
> the index. You can't remove the file because pg_index thinks the index
> is proper and exists.
>
> I am kind of stumped.
>
> --
> Bruce Momjian| http://candle.pha.pa.us
> [EMAIL PROTECTED] | (610) 853-3000
> + If your life is a hard drive, | 830 Blythe Avenue
> + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
> Index: src/backend/catalog/index.c
> ===
> RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/catalog/index.c,v
> retrieving revision 1.144
> diff -c -r1.144 index.c
> *** src/backend/catalog/index.c 2001/03/22 06:16:10 1.144
> --- src/backend/catalog/index.c 2001/03/30 22:55:54
> ***
> *** 864,869
> --- 864,876
> indexInfo->ii_NumKeyAttrs < 1)
> elog(ERROR, "must index at least one attribute");
>
> + if (heapRelationName && !allow_system_table_mods &&
> + IsSystemRelationName(heapRelationName) && IsNormalProcessingMode())
> + {
> + elog(ERROR, "You can not create indexes on system tables: '%s'",
> + heapRelationName);
> + }
> +
> /*
>* get heap relation oid and open the heap relation
>*/
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: [SQL] Re: pg_dump potential bug -UNIQUE INDEX on PG_SHADOW Dont!! HELP
Bruce Momjian <[EMAIL PROTECTED]> writes: > test=> CREATE UNIQUE INDEX shadow_index ON pg_shadow (usename); > CREATE > test=> select * from pg_shadow; > ERROR: Index 'pg_shadow_sysid_index' does not exist > test=> \q > $ psql test > psql: FATAL 1: Index 'pg_shadow_name_index' does not exist > $ > Notice the user wanted an index named shadow_index, but the error > mentioned is pg_shadow_name_index. What's failing is catcache lookups on pg_shadow. The catcache has table entries that claim that there are indexes on pg_shadow(usename) and pg_shadow(usesysid). The system would not work at all, except that catcache's use of these indexes is defeated by sanity-check code that notices that relhasindex is FALSE for pg_shadow (line 880 of catcache.c). As soon as you create an index on pg_shadow, relhasindex becomes TRUE and catcache.c starts trying to use these nonexistent indexes for routine operations like ACL permissions checks. So, nothing works anymore. We ought to create those indexes someday ;-) regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] ODBC Problems
Hi EveryBody When i connect to my database in windows98 (ODBC) to the server in Linux, i can execute SELECT staments , but no INSERT or UPDATE staments... the error 'Key Violation ..Connection is readonly , only select staments are allowed' appears. the user was created with CREATEUSER (SuperUser) but nothing.. i can't write to my tables...what is the problem??? Thanks!!!1
[HACKERS] Permissions on All Tables
Hi EveryBody!!! How can i set permission for any user (SELECT for example) in all tables (any database) without list all tables in GRANT stament? Thanks!
[HACKERS] Table Structure
Hi EveryBody: How can i get the structure of a table (Fields names, data types, etc)??? Thanks
[HACKERS] clearing on-row commit status bits
Hi, I'm in search of a hack that will allow me to clear the on-row commit status bits. Any assistance would greatly be appreciated. Thanks, Dave Perkins ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] elog/internationalization thread
I have added the recent elog and internationalization email thread to TODO.detail. (Wow, I spelled internationalization right the first time.) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] testing last sanpshot in QNX platform
Strange. The compiler work with all my old project and also with the old version of postgresql. However I will search the problem and I will post the risult. Maurizio . - Original Message - From: "Peter Eisentraut" <[EMAIL PROTECTED]> To: "Maurizio" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, March 30, 2001 5:38 PM Subject: Re: [HACKERS] testing last sanpshot in QNX platform > Maurizio writes: > > > configure:6840: checking test program > > configure:6849: gcc -o conftest.map conftest.c -lz -lunix -lresolv -lPW -lgen -lBSD -lcompat -lld -ldld -llc -lI PC -lipc -lnsl -lsocket -ldl -lm -lbsd -lsfio -lunix 1>&5 > > cc warning: cc: cannot find library 'resolv' > > cc warning: cc: cannot find library 'PW' > [etc] > > This means that earlier in configure it was determined that these > libraries existed (see "checking for main in -lxxx") but now it doesn't > work anymore. Not sure why this could happen, given that people have used > QNX previously. (At least they got past this point.) > > What's curious here is that it wants to name the output program > "conftest.map", which looks like it detected ".map" as the executable > extension (ordinarily only used for ".exe" on Windows). What's also > curious is that the error message doesn't look like anything "gcc" would > produce. I think this might be a case of a messed up compiler > installation and/or a case of a user cheating with configure to cover up > for that fact. ;-) Some more information about your compiler setup and a > peek into config.log near the compiler detection tests could shed some > light onto the problem. > > -- > Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ > ---(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] Re: 7.1 pg_dump fails for user-defined types (release stopper?)
At 15:49 31/03/01 +1000, Philip Warner wrote: > >(I *think* that's right...). > I've sent a version of this to patches. I have verified it dumps & restores the regression db, excluding the f_star data, which is I *hope* a the one acceptable failing of pg_dump (ie. reordered attrs in tables). Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
