[BUGS] BUG #5733: Strange planer behaviour with inherited tables
The following bug has been logged online: Bug reference: 5733 Logged by: Marcus Wirsing Email address: m...@hesotech.de PostgreSQL version: 9.0.1 Operating system: Windows XP 32 Description:Strange planer behaviour with inherited tables Details: when I execute the following script, the planer always makes a seq. scan over all child tables. drop schema if exists schema_0 cascade; drop schema if exists schema_1 cascade; drop schema if exists schema_2 cascade; create schema schema_0; create schema schema_1; create schema schema_2; CREATE TABLE schema_0.testtab ( entry bigserial NOT NULL, status integer, chnsetid integer, dt_package timestamp with time zone, dwell interval, cnt_mv integer, min_mv real[], PRIMARY KEY (entry) ); create table schema_1.testtab (primary key(entry)) inherits (schema_0.testtab); create table schema_2.testtab (primary key(entry)) inherits (schema_0.testtab); EXPLAIN SELECT entry FROM schema_0.testtab where entry > 1000 order by entry limit 1; result: "Limit (cost=62.73..62.73 rows=1 width=8)" " -> Sort (cost=62.73..64.66 rows=771 width=8)" "Sort Key: schema_0.testtab.entry" "-> Result (cost=0.00..58.88 rows=771 width=8)" " -> Append (cost=0.00..58.88 rows=771 width=8)" "-> Seq Scan on testtab (cost=0.00..19.63 rows=257 width=8)" " Filter: (entry > 1000)" "-> Seq Scan on testtab (cost=0.00..19.63 rows=257 width=8)" " Filter: (entry > 1000)" "-> Seq Scan on testtab (cost=0.00..19.63 rows=257 width=8)" " Filter: (entry > 1000)" when I remove the min_mv real[] the planer makes an index scan as expected. " -> Sort (cost=70.55..73.30 rows=1101 width=8)" "Sort Key: schema_0.testtab.entry" "-> Result (cost=7.09..65.05 rows=1101 width=8)" " -> Append (cost=7.09..65.05 rows=1101 width=8)" "-> Bitmap Heap Scan on testtab (cost=7.09..21.68 rows=367 width=8)" " Recheck Cond: (entry > 1000)" " -> Bitmap Index Scan on testtab_pkey (cost=0.00..7.00 rows=367 width=0)" "Index Cond: (entry > 1000)" "-> Bitmap Heap Scan on testtab (cost=7.09..21.68 rows=367 width=8)" " Recheck Cond: (entry > 1000)" " -> Bitmap Index Scan on testtab_pkey (cost=0.00..7.00 rows=367 width=0)" "Index Cond: (entry > 1000)" "-> Bitmap Heap Scan on testtab (cost=7.09..21.68 rows=367 width=8)" " Recheck Cond: (entry > 1000)" " -> Bitmap Index Scan on testtab_pkey (cost=0.00..7.00 rows=367 width=0)" "Index Cond: (entry > 1000)" -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5726: Re: BUG #5723: Can not start postgres after install
The following bug has been logged online: Bug reference: 5726 Logged by: Marcus Email address: marcusboos...@mailinator.com PostgreSQL version: 9.0.1 Operating system: Ubuntu 10.10 Description:Re: BUG #5723: Can not start postgres after install Details: On 10/25/2010 10:50 PM, Marcus wrote: >> The following bug has been logged online: >> Bug reference: 5723 >> Logged by: Marcus >> Email address: marcusboos...@mailinator.com >> PostgreSQL version: 9.0.1 >> Operating system: Ubuntu 10.10 >> Description:Can not start postgres after install >> Details: >> A user installing from source to a local directory. >> Builds and installs fine, but panics when starting the server. >> uname -a: >> Linux myname 2.6.35-22-server #35-Ubuntu SMP Sat Oct 16 22:02:33 UTC 2010 >> x86_64 GNU/Linux >> Tried on ext3 and ext4 filesystems. > You mean you've tried putting $HOME/var/pgsql on both ext3 and ext4? >> $HOME/opt/postgresql/bin/pg_ctl -D $HOME/var/pgsql/data start >> server starting >> LOG: database system was shut down at 2010-10-25 01:09:49 EDT >> PANIC: could not open file "pg_xlog/0001" (log file 0, segment 0): Invalid argument > What're the mount options used? The output of the "mount" command without arguments would be useful. Yes I did an initdb on $HOME/var/pgsql/data, that wasn't it. After consulting the irc channel I was shown a workaround: In postgresql.conf I had to explicitly set 'wal_sync_method = fsync' (which was commented out), for whatever reason the default was causing the panic. This is after a new Ubuntu 10.10 install, mount: /dev/mapper/myname-root on / type ext4 (rw,errors=remount-ro,commit=0) proc on /proc type proc (rw,noexec,nosuid,nodev) none on /sys type sysfs (rw,noexec,nosuid,nodev) fusectl on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) none on /dev type devtmpfs (rw,mode=0755) none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) none on /dev/shm type tmpfs (rw,nosuid,nodev) none on /var/run type tmpfs (rw,nosuid,mode=0755) none on /var/lock type tmpfs (rw,noexec,nosuid,nodev) /dev/sdb1 on /boot type ext2 (rw) /home/myname/.Private on /home/myname type ecryptfs (ecryptfs_sig=c1f838f60a32df99,ecryptfs_fnek_sig=aa11aefa959dd3c5,ecryptfs_c ipher=aes,ecryptfs_key_bytes=16) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5723: Can not start postgres after install
The following bug has been logged online: Bug reference: 5723 Logged by: Marcus Email address: marcusboos...@mailinator.com PostgreSQL version: 9.0.1 Operating system: Ubuntu 10.10 Description:Can not start postgres after install Details: A user installing from source to a local directory. Builds and installs fine, but panics when starting the server. uname -a: Linux myname 2.6.35-22-server #35-Ubuntu SMP Sat Oct 16 22:02:33 UTC 2010 x86_64 GNU/Linux Tried on ext3 and ext4 filesystems. ./configure --prefix=$HOME/opt/postgres ... (good) ./make && make install ... (good) $HOME/opt/postgresql/bin/pg_ctl -D $HOME/var/pgsql/data start server starting LOG: database system was shut down at 2010-10-25 01:09:49 EDT PANIC: could not open file "pg_xlog/0001" (log file 0, segment 0): Invalid argument LOG: startup process (PID 5010) was terminated by signal 6: Aborted LOG: aborting startup due to startup process failure -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5140: initdb crashes
The following bug has been logged online: Bug reference: 5140 Logged by: Marcus Lundblad Email address: marcus.lundb...@mogul.com PostgreSQL version: 8.3.8 Operating system: Solaris 10 Description:initdb crashes Details: Hi I compiled version 8.3.8 of postgres on a Solaris 10 machine. When running initdb it crashes like this: postg...@webbkartbas02> /usr/local/postgres/bin/initdb -D /usr/local/postgres/data/ -d Running in debug mode. VERSION=8.3.8 PGDATA=/usr/local/postgres/data share_path=/usr/local/postgres/share PGPATH=/usr/local/postgres/bin POSTGRES_SUPERUSERNAME=postgres POSTGRES_BKI=/usr/local/postgres/share/postgres.bki POSTGRES_DESCR=/usr/local/postgres/share/postgres.description POSTGRES_SHDESCR=/usr/local/postgres/share/postgres.shdescription POSTGRESQL_CONF_SAMPLE=/usr/local/postgres/share/postgresql.conf.sample PG_HBA_SAMPLE=/usr/local/postgres/share/pg_hba.conf.sample PG_IDENT_SAMPLE=/usr/local/postgres/share/pg_ident.conf.sample The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale C. The default database encoding has accordingly been set to SQL_ASCII. The default text search configuration will be set to "english". fixing permissions on existing directory /usr/local/postgres/data ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers/max_fsm_pages ... 32MB/204800 creating configuration files ... ok creating template1 database in /usr/local/postgres/data/base/1 ... DEBUG: invoking IpcMemoryCreate(size=38264832) DEBUG: creating and filling new WAL file DEBUG: done creating and filling new WAL file LOG: database system was shut down at 2009-10-27 15:26:27 CET LOG: incorrect resource manager data checksum in record at 0/20 LOG: invalid primary checkpoint record LOG: invalid secondary checkpoint link in control file PANIC: could not locate a valid checkpoint record Abort - core dumped child process exited with exit code 134 initdb: removing contents of data directory "/usr/local/postgres/data" The following params to ./configure was passed when compiling postgres: ./configure --prefix=/usr/local/postgres/ --with-pam --with-libedit-preferred --with-libxml --with-libxslt --with-gssapi --enable-thread-safety --enable-dtrace--with-includes=/usr/local/include:/usr/include:/usr/gcc/incl ude:/usr/sfw/include/ --with-libs=/usr/local/lib:/usr/gcc/lib:/usr/lib --with-libraries=/usr/local/lib:/usr/gcc/lib:/usr/lib the version of gcc is: sparc-sun-solaris2.10-gcc (GCC) 4.2.1 (20090222) (gccfss) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4544: Wiki user update error
The following bug has been logged online: Bug reference: 4544 Logged by: Marcus Kempe Email address: [EMAIL PROTECTED] PostgreSQL version: N/A Operating system: N/A Description:Wiki user update error Details: While trying to update my user preferences in the wiki, I get the error below. URL for the page in question: http://wiki.postgresql.org/wiki/Special:Preferences Warning: pg_query_params(): Query failed: ERROR: function community_login_setinfo(unknown, unknown, unknown, unknown) does not exist LINE 1: SELECT community_login_setinfo($1, $2, $3, $4) ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts. in /usr/local/www/mediawiki/extensions/PgAuthPlugin.php on line 224 Warning: pg_num_rows(): supplied argument is not a valid PostgreSQL result resource in /usr/local/www/mediawiki/extensions/PgAuthPlugin.php on line 226 Warning: pg_free_result(): supplied argument is not a valid PostgreSQL result resource in /usr/local/www/mediawiki/extensions/PgAuthPlugin.php on line 236 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Error connecting
So it just suddenly stopped working after 1 week for the 2nd time straight. The first time i reinstalled everything, lost database but it worked, now it just doesnt connect. What should i do? I use windows vista, run as administrator and everything
[BUGS] BUG #3958: Self-Join Group-By Clause Produces Incorrect Results
The following bug has been logged online: Bug reference: 3958 Logged by: Marcus Torres Email address: [EMAIL PROTECTED] PostgreSQL version: 8.19 Operating system: Linux - Ubuntu Description:Self-Join Group-By Clause Produces Incorrect Results Details: This is a repost of my original bug with self-contained sql to reproduce the problem: I wrote a simple self-join query to sum the transaction count of different types of records in a audit table and the result set for the different sum totals was the same which is incorrect. SQL: -- DROP TABLE T_AUDIT; DROP TABLE T_POLICY; CREATE TABLE T_AUDIT ( ID integer NOT NULL, POLICY_ID integer NOT NULL, AUDIT_DATE date NOT NULL, AUDIT_TYPE_CODE character varying(50) NOT NULL, TXN_COUNT integer NOT NULL DEFAULT 1 ) WITHOUT OIDS TABLESPACE pg_default; ALTER TABLE t_audit OWNER TO postgres; GRANT ALL ON TABLE t_audit TO public; CREATE TABLE T_POLICY ( ID integer NOT NULL, CONTENT_POLICY_NAME character varying(50) NOT NULL ) WITHOUT OIDS TABLESPACE pg_default; ALTER TABLE t_audit OWNER TO postgres; GRANT ALL ON TABLE t_policy TO public; INSERT INTO T_POLICY VALUES (100, 'TEST POLICY'); INSERT INTO T_AUDIT VALUES (1000, 100, '2008-01-01','CONTENT_1',1); INSERT INTO T_AUDIT VALUES (1001, 100, '2008-01-01','CONTENT_1',1); INSERT INTO T_AUDIT VALUES (1002, 100, '2008-01-01','CONTENT_1',1); INSERT INTO T_AUDIT VALUES (1003, 100, '2008-01-01','CONTENT_1',1); INSERT INTO T_AUDIT VALUES (1004, 100, '2008-01-01','CONTENT_1',1); INSERT INTO T_AUDIT VALUES (1005, 100, '2008-01-01','CONTENT_2',1); INSERT INTO T_AUDIT VALUES (1006, 100, '2008-01-01','CONTENT_2',1); SELECT A1.AUDIT_DATE, P.CONTENT_POLICY_NAME, SUM(A1.TXN_COUNT) AS SUM_1, SUM(A2.TXN_COUNT) AS SUM_2 FROM T_AUDIT A1, T_AUDIT A2, T_POLICY P WHERE P.ID = A1.POLICY_ID AND P.ID = A2.POLICY_ID AND A1.POLICY_ID = A2.POLICY_ID AND A1.AUDIT_DATE = A2.AUDIT_DATE AND A1.AUDIT_TYPE_CODE = 'CONTENT_1' AND A2.AUDIT_TYPE_CODE = 'CONTENT_2' GROUP BY A1.AUDIT_DATE, P.CONTENT_POLICY_NAME; ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #3914: Self-Join Group-By Clause Produces Incorrect Results
The following bug has been logged online: Bug reference: 3914 Logged by: Marcus Torres Email address: [EMAIL PROTECTED] PostgreSQL version: 8.19 Operating system: Linux - Ubuntu Description:Self-Join Group-By Clause Produces Incorrect Results Details: I wrote a simply self-join query to sum the transaction count of different types of records in a audit table and the result set for the different sum totals was the same, which is highly incorrect. If I copy the same records from t_audit to another table and run the same query which is not a self-join, it worksvery strange Query: select a1.audit_julian_date AS DATE, t.cont_pol_name as CONT_POLICY, sum(a1.txn_count) as CONTENT_COUNT1, sum(a2.txn_count) as CONTENT_COUNT2 from t_audit a1, t_audit a2, tmp_cp_ref t where t.cont_exp_id = a1.txn_ent_id and t.cont_exp_id = a2.txn_ent_id and a1.txn_ent_id = a2.txn_ent_id and a1.audit_julian_date = a2.audit_julian_date and a1.audit_type_code = 'CONTENT_1' and a1.audit_julian_date >= 2454476 and a2.audit_type_code = 'CONTENT_2' and a2.audit_julian_date >= 2454476 GROUP BY a1.audit_julian_date, t.cont_pol_name DATECONT_POLICY CONTENT_COUNT1 CONTENT_COUNT2 -- 2454483|CP1|6|6 2454484|CP1|143,480|143,480 2454485|CP1|137,133|137,133 2454487|CP1|30,036|30,036 2454488|CP1|889,344|889,344 2454489|CP1|735,556|735,556 2454492|CP1|271,572|271,572 2454493|CP1|719,496|719,496 2454494|CP1|306,867|306,867 2454495|CP1|530,868|530,868 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #1775: UTF8 to ISO does not convert the german "sharp s" (ß)
Hi, PE> PostgreSQL does not support UTF8 locales on Windows, but the character PE> conversion should work the same on all platforms, shouldn't it? It works pretty fine even under win32, all umlauts are coverted as expexted, except for the "ß" (ß). For example, "Köln" converts to "Köln", but ""Groà Kreutz" results in an empty string. -- Mit freundlichen Grüssen Marcus Rapheltmailto:[EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1775: UTF8 to ISO does not convert the german "sharp s" (ß)
Hi Tatsuo, Am Mittwoch, 20. Juli 2005 um 01:00 schrieben Sie: TI> conversion tables. So if german umlauts are converted fine, there's no TI> reason the conversion for german sharp s does not work. TI> Marcus, TI> Can you give me the exact error message from PostgreSQL when the TI> conversio failed? Well - actually, there IS no error message, convert() just returns an empty sting. In detail, here's what I did: -Set up PostgreSQL (Ascii) -Imported the opengeodb http://sourceforge.net/project/showfiles.php?group_id=132421 As they offer a PostgreSQL dump, I chose this one. -Imported the dump using pgAdminIII -Created a view that returns all german cities with ZIP and opengeodb-locationID: CREATE OR REPLACE VIEW orte_de AS SELECT code.text_val AS plz, code.loc_id, town.text_val AS ort FROM geodb_hierarchies hi, geodb_textdata state, geodb_textdata town, geodb_textdata code WHERE hi.id_lvl2 = state.loc_id AND state.text_val = 'DE'::text AND state.text_type = 50011 AND town.loc_id = hi.loc_id AND town.text_type = 50010 AND code.loc_id = town.loc_id AND code.text_type = 50030; So now I've got three columns: "plz" (zip), "ort" (city) and loc_id. Assuming I want to retrieve cites in the Hamburg / Hannover area... (perfect for this task, as they have pretty strange city names there :) SELECT plz, loc_id, ort, convert(ort using utf_8_to_iso_8859_1) as ort_conv from orte_de where plz between 2 and 3 order by ort_conv This query returns empty values for "ort_conv" if "ort" contains a sharp s. Btw, it seems like it is the same for "Ä" (Ä), have a look at loc_id 25182. -- Mit freundlichen Grüssen Marcus Rapheltmailto:[EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #1775: UTF8 to ISO does not convert the german "sharp s" (ß)
Hi, Am Mittwoch, 20. Juli 2005 um 10:27 schrieben Sie: TI> Problem here is the result of convert(ort using utf_8_to_iso_8859_1) TI> is ISO-8859-1 but your database encoding is UTF-8, Not exactly, my database is in iso_8859_1, only the opengeodb-dump is solely available in utf-8. The whole thing is no problem so far, as I can convert the values in the application that uses the data - I just wanted to let you know. TI> I guess what you want to do is: TI> SELECT plz, loc_id, ort from orte_de TI> where plz between 2 and 3 TI> order by convert(ort using utf_8_to_iso_8859_1) Well, that was a fantasy-query :) just to show some "odd" values, I do not need that much data in the application. Currently, I cannot retrieve ready-converted iso data from the orte_de view, as converted names that contain "ß" are not shown... -- Mit freundlichen Grüssen Marcus Rapheltmailto:[EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: 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
[BUGS] BUG #1775: UTF8 to ISO does not convert the german "sharp s" (ß)
The following bug has been logged online: Bug reference: 1775 Logged by: Marcus Raphelt Email address: [EMAIL PROTECTED] PostgreSQL version: latest Operating system: WinXP (dev), Win2000 (server) Description:UTF8 to ISO does not convert the german "sharp s" (ß) Details: Hi, I currently have a iso_8859_1 app and included the opengeodb tables to have a set of german cities and zipcodes. http://opengeodb.sourceforge.net/index.php?FrontPage_en I downloaded this dump: http://prdownloads.sourceforge.net/opengeodb/opengeodb-0.2.3c-UTF8-postgres. zip?download They offer a Postgresql dump that can be imported without hassle, but is in UTF8. I did several attempts using convert() to convert the city names to iso. It works, and it also works fine on german umlauts (äöü), but it seems like convert() does NOT convert the german "Ã" / sharp s / ß... cheers, marcus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #1581: Problem with capitalised DB names...
Hi Bruno, Oops, I've overlooked that passage. Thanks for your help and sorry for wasting your time. Best Ragards Marcus On Apr 11, 2005 6:18 PM, Bruno Wolff III <[EMAIL PROTECTED]> wrote: > On Mon, Apr 11, 2005 at 09:37:08 +0100, > "Marcus v. Scotti" <[EMAIL PROTECTED]> wrote: > > > > Thanks... (maybe include this in the manuals, I couldn't find this > > information...) > > It is: > http://developer.postgresql.org/docs/postgres/sql-syntax.html#SQL-SYNTAX-IDENTIFIERS > -- Marcus v. Scotti Director Fry-IT LTD www.fry-it.com ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] BUG #1581: Problem with capitalised DB names...
Hi Bruno,
Thanks... (maybe include this in the manuals, I couldn't find this
information...)
Best Regards
Marcus
On Apr 10, 2005 11:23 PM, Bruno Wolff III <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 05, 2005 at 18:09:25 +0100,
> "Marcus v. Scotti" <[EMAIL PROTECTED]> wrote:
> >
> > Description:Problem with capitalised DB names...
> > Details:
> >
> > When trying to grant database privileges to a group of users there is no way
> > to do this if the database name is capitalised (i.e. db-name = Test). The
> > error message when performing the grant operation:
> >
> > grant all on DATABASE test to group tgroup;
> >
> > is:
> >
> > ERROR: database "test" does not exist
> >
> > I have used capitalisation an a number of databases, so this now seems to
> > require me to rename them all in to lower-case...
>
> You need to use double quotes (") around database, table or column names that
> are not all lowercase.
>
--
Marcus v. Scotti
Director
Fry-IT LTD
www.fry-it.com
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
[BUGS] BUG #1581: Problem with capitalised DB names...
The following bug has been logged online: Bug reference: 1581 Logged by: Marcus v. Scotti Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4.7 Operating system: Linux Description:Problem with capitalised DB names... Details: When trying to grant database privileges to a group of users there is no way to do this if the database name is capitalised (i.e. db-name = Test). The error message when performing the grant operation: grant all on DATABASE test to group tgroup; is: ERROR: database "test" does not exist I have used capitalisation an a number of databases, so this now seems to require me to rename them all in to lower-case... ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Database Grants Bug
On Mon, 2003-08-18 at 10:31, Andreas Pflug wrote: > > > AFAIR pgAdmin2 does have a grant utility for this. pgAdmin3 has this on > the TODO for the next version. > > Regards, > Andreas > I just used pgAdmin2's security wizard for this. Very nice. Just what I needed. Thanks, Marcus ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Database Grants Bug
On Mon, 2003-08-18 at 09:29, Joe Conway wrote: > Marcus England wrote: > Again, I don't know what your definition of "most, if not all other > DBMS's" is, but a quick read through my MSSQL2000 manual indicates SQL > Server is no different from Postgres in this regard. Same for Oracle 9i. > I'd say that covers the majority of DBMS installations. I don't have a > DB2 manual handy to check. I guess I meant the ability to grant permissions easily at the DB level. It's trivial in SQL Server via Enterprise Manager - no SQL needed. I assume DB2 and Oracle have similar facilities, not necessarily in SQL. Perhaps pgadmin has this ability? Thanks a lot for the help/clarification and the function, Marcus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] Database Grants Bug
Thank you Joe.
IMHO, this is confusing and limiting for Administrators who wish to
grant privileges beyond CREATE, TEMPORARY, and TEMP across all tables in
a database. Something I believe most, if not all other DBMS's do. "ALL"
isn't very consistent.
Reading the comments in the documentation, apparently I'm not the only
one who's confused about ALL.
Please correct me if I'm missing something here.
Marcus
On Sun, 2003-08-17 at 22:48, Joe Conway wrote:
> Marcus England wrote:
> > Grants do not work at the database level using the syntax mentioned in
> > the documentation. i.e.:
> >
> > GRANT ALL ON DATABASE dbname TO GROUP groupname;
> >
> > Or
> >
> > GRANT ALL ON DATABASE dbname TO username;
> >
>
> Works here:
>
> regression=# select version();
> version
> -
> PostgreSQL 7.3.3 on i686-redhat-linux-gnu, compiled by GCC 2.96
> (1 row)
>
> regression=# GRANT ALL ON DATABASE regression TO GROUP grp1;
> GRANT
> regression=# GRANT ALL ON DATABASE regression TO user1;
> GRANT
>
> You need to be more specific in what you mean by "do not work". Do you
> get an error? What exactly is not working?
>
> Perhaps you expect more than you should -- re-read the docs,
> specifically the section quoted here:
>
> GRANT { { CREATE | TEMPORARY | TEMP } [,...] | ALL [ PRIVILEGES ] }
> ON DATABASE dbname [, ...]
> TO { username | GROUP groupname | PUBLIC } [, ...]
>
> In the context of DATABASE, ALL means "CREATE & TEMPORARY & TEMP",
> nothing more, nothing less. Further reading provides:
>
> CREATE
> For databases, allows new schemas to be created within the database.
>
> TEMPORARY
> TEMP
> Allows temporary tables to be created while using the database.
>
> Are these not working?
>
> HTH,
>
> Joe
>
>
> ---(end of broadcast)---
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
---(end of broadcast)---
TIP 8: explain analyze is your friend
[BUGS] Database Grants Bug
=== POSTGRESQL BUG REPORT TEMPLATE Your name : Marcus England Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : Intel Pentium Operating System (example: Linux 2.0.26 ELF) : Linux 2.4.20 Redhat PostgreSQL version (example: PostgreSQL-7.3.4): PostgreSQL-7.3.4 Compiler used (example: gcc 2.95.2) : gcc 3.2.2 Please enter a FULL description of your problem: Grants do not work at the database level using the syntax mentioned in the documentation. i.e.: GRANT ALL ON DATABASE dbname TO GROUP groupname; Or GRANT ALL ON DATABASE dbname TO username; No errors are reported. Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- Using any database with any user or group should do the trick. If you know how this problem might be fixed, list the solution below: -
