Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
On Thu, 2003-06-05 at 14:16, Josh Berkus wrote: Rod, 4) Does anyone else have any comments on the proposed re-ordering? Since we're painting a shed, does it make sense to put the items in alphabetical order for each section? I thought about that, yes. However, I find that most items have a logical order that is not alphabetical. Take the WAL section for example: Excellent point. BTW, everyone: I do not seem to be receiving any Postgresql.org mail since the server crash restoration. So please cc: any comments directly to me! You re-subscribed I assume... -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
[HACKERS] cvs ETA?
Is there any ETA for cvs? Dave -- Dave Cramer [EMAIL PROTECTED] fastcrypt ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] default locale considered harmful? (was Re: [GENERAL]
On Thu, Jun 05, 2003 at 09:44:21AM -0600, scott.marlowe wrote: On Thu, 5 Jun 2003, Nigel J. Andrews wrote: Everything Nigel just wrote plus one thing. If it comes down to it, we could always require a --locale setting and refuse to initdb without it. That way, whether it's in an RPM or from source, somebody somewhere along the line has to choose something. Yeah, that way the RPM guys would put the --locale taking the locale from the environment and you're back to ground zero. There's no point in forcing things down the throat of users using this kind of mechanisms, because someone is going to automate the thing along the way. What is needed is a way to make the user aware of his system's configuration. -- Alvaro Herrera ([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])
Re: [HACKERS] UPDATE ... SET = DEFAULT
Rod Taylor [EMAIL PROTECTED] writes: It would seem a new primnode (change InsertDef into SetDefault or similar) will be required with some executor logic. It is not the executor's business to know about defaults. The rewriter is the place where defaults get inserted - see rewriteTargetList(). Note that default NULL will have to be treated a little differently from what we do for INSERT, since the, um, default behavior of UPDATE is to preserve columns rather than replace 'em with nulls. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
Rod, 4) Does anyone else have any comments on the proposed re-ordering? Since we're painting a shed, does it make sense to put the items in alphabetical order for each section? I thought about that, yes. However, I find that most items have a logical order that is not alphabetical. Take the WAL section for example: fsync needs to go first, because if it is set to false the rest of the WAL settings don't matter. wal_sync_method and wal_buffers are the most important (or, at least, most likely to be tinkered with) settings so they sould go immdiately after. checkpoint_segments, checkpoint_timeout, commit_delay, commit_siblings are all directly related and should to appear in that order (which, oddly enough, happens to be alphabetical). wal_debug is seldom used outside of Postgresql source development or unusual system failures, and should therefore go last. I have tried to order other parameters by applying the same logic, which essentially amounts to: order by most important/most likely to be changed, grouping settings that need to be manipulated together. I'd be happy to hear your comments on my application of that logic. BTW, everyone: I do not seem to be receiving any Postgresql.org mail since the server crash restoration. So please cc: any comments directly to me! -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] UPDATE ... SET = DEFAULT
On Thu, 2003-06-05 at 16:45, Tom Lane wrote: Rod Taylor [EMAIL PROTECTED] writes: It would seem a new primnode (change InsertDef into SetDefault or similar) will be required with some executor logic. It is not the executor's business to know about defaults. The rewriter is the place where defaults get inserted - see rewriteTargetList(). Ahh, thanks. I was fairly sure I had the wrong spot. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] default locale considered harmful? (was Re: [GENERAL]
On Thu, 5 Jun 2003, Peter Eisentraut wrote: scott.marlowe writes: If it comes down to it, we could always require a --locale setting and refuse to initdb without it. That way, whether it's in an RPM or from source, somebody somewhere along the line has to choose something. By default, you choose when you install or configure your operating system. In most cases, the region where you install your operating system and the region where you run your database is the same, so equating these settings by default is reasonable. But it's not that simple. If one could flip a switch and change a postgresql installation from one locale to another, then hey, no big deal. If indexes on text worked right in other locales it would be no big deal. If you don't choose locale=C with doing initdb then you have to backup the whole database, reinitdb, and restore it in order to switch to it. If the postgresql engine could use indexes well in all locales then it would be reasonable to pick up the environmental locale. As long as locale C is the only one that can use indexes on text, it's not reasonable to use the locale of the environment without knowing what the user really wants to do with the database. Especially since most of the folks I know who download it are going to prefer a locale of C to en_US or whatnot, since they'll likely want fast indexed access on text types. I would at least suggest that certain locales default to be coerced to C if the user doesn't pick one. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Result of a query(Need Help)
Srikanth M [EMAIL PROTECTED] writes: Could anyone tell me where excatly the result of a query is stored after the query is passed to pg_exec_query_string function and before it is printed. It isn't stored anywhere --- tuples are passed to the frontend as they are generated. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] default locale considered harmful? (was Re: [GENERAL]
scott.marlowe writes: If it comes down to it, we could always require a --locale setting and refuse to initdb without it. That way, whether it's in an RPM or from source, somebody somewhere along the line has to choose something. By default, you choose when you install or configure your operating system. In most cases, the region where you install your operating system and the region where you run your database is the same, so equating these settings by default is reasonable. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] This is not gonna do
The recent change to make log_min_messages SUSET provokes the following behavior: $ export PGOPTIONS=-d 5 $ psql psql: FATAL: 'log_min_messages': permission denied $ Considering that I *am* superuser, this is quite unacceptable. If you don't want to revert the change, propose another solution. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] default locale considered harmful? (was Re: [GENERAL]
scott.marlowe writes: If indexes on text worked right in other locales it would be no big deal. They will in version 7.4, so all these concerns about trading off locale use vs. performance will become obsolete. -- Peter Eisentraut [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])
Re: [HACKERS] Problems with renaming a column
On Thu, 2003-06-05 at 11:11, Rod Taylor wrote:
On Wed, 2003-06-04 at 22:28, Christopher Kings-Lynne wrote:
Which ones are missing, and should we really be looking at creating
a
pg_definition_schema instead?
Missing:
Database, schema, table, domain, cast, conversion, function...
Maybe a definition schema might be better.dunno...it would need to
use
the pg_get_*def functions anyway methinks.
yeah, i would think it would, but isn't the point of the information
schema to help hide the back end tech?
As an interface writer, do you prefer dealing with functions like
pg_get_constraintdef() or a view like the information schema provides?
I would think it is easier to get the information from the information
schema. That's most like what we're doing now getting the information
from the pg_* tables and istm it's easier to browse the information
schema than dig through function definitions. To be fair Chris tends to
hack on pg_dump at a much deeper level than I on either pg_dump or psql,
so he might be more familiar with the functions and have a different
viewpoint.
The function doesn't easily allow determination of items such as the ON
UPDATE or ON DELETE type (statement parsing is required), but the
information schema gives the information in a segregated manner.
Well, the biggest pain in the arse I had to deal with in phpPgAdmin was
the handling of permissions, specifically due to having to parse through
the relacl information. I was so glad when Chris fixed up my half
working implementation.
The pg_get_*def() functions seem to have been created primarily for psql
and pg_dump.
yeah. again Chris tends to hack on pg_dump so he might see it
differently than I (and I haven't looked at psql in months).
(He's on holiday for the next few days btw which is why I'm chiming in)
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] large objects
On Fri, 6 Jun 2003, Tom Lane wrote: Nigel J. Andrews [EMAIL PROTECTED] writes: Now, I did a little bit of testing and when doing a \lo_export oid filename in psql connected via localhost a SIGPIPE is generated in write() in libc and psql quit, without printing any message to the terminal. Perhaps interestingly the file that gets written is always 65536 bytes long. Hm. Are you using an SSL connection? There are some known bugs in the SSL support in 7.3.1. It's supposed to be fixed in 7.3.3, though I've not tried it myself. Damn, yes I am, I noticed the notice when connecting but then didn't think anything of it. Thanks Tom, I'll check that later when I do have time (shouldn't have wasted the precious minutes joining the NULL != war). -- Nigel Andrews ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] large objects
Nigel J. Andrews [EMAIL PROTECTED] writes: Now, I did a little bit of testing and when doing a \lo_export oid filename in psql connected via localhost a SIGPIPE is generated in write() in libc and psql quit, without printing any message to the terminal. Perhaps interestingly the file that gets written is always 65536 bytes long. Hm. Are you using an SSL connection? There are some known bugs in the SSL support in 7.3.1. It's supposed to be fixed in 7.3.3, though I've not tried it myself. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Debugging tool for viewing parse trees?
I've gotten back to working on the SQL99 version of updateable views and I'ld like to confirm my current understanding of the parse tree data structure. Is there a debugging-type tool for outputting the parse tree for a given query? Eric Nielsen ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] 7.3.3 COMPILE FAILURE: pg_dump (fwd)
--On Saturday, June 07, 2003 10:42:31 -0500 Larry Rosenman [EMAIL PROTECTED] wrote: cc -O -g -I../../../src/interfaces/libpq -I../../../src/include -I/usr/local/include -DBINDIR=\/usr/local/pgsql/bin\ -c -o pg_dump.o pg_dump.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled UX:acomp: ERROR: pg_dump.c, line 192: incomplete struct/union/enum option: long_options UX:acomp: ERROR: pg_dump.c, line 193: too many struct/union initializers UX:acomp: ERROR: pg_dump.c, line 193: cannot recover from previous errors gmake[3]: *** [pg_dump.o] Error 1 gmake[3]: Leaving directory `/home/ler/pg-dev/postgresql-7.3.3/src/bin/pg_dump' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/ler/pg-dev/postgresql-7.3.3/src/bin' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/home/ler/pg-dev/postgresql-7.3.3/src' gmake: *** [all] Error 2 $ on UnixWare 7.1.3 modifying pg_config.h to NOT define GETOPT_LONG fixes it. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
I kind of prefer the way things were grouped together in 7.2 vs. 7.3. If I
needed to check out connection information or look at query tuning flags,
they were all right next to each other and I didn't have to scroll back and
forth through the list. Luckily most of the topical variables share somewhat
common names (max_fsm_relations and max_fsm_pages) or else it would really be
easy to overlook some settings.
Robert Treat
On Saturday 07 June 2003 12:33 pm, Bruce Momjian wrote:
I think people thought if you were doing SHOW ALL, you were looking for
a specific variable, so alphabetical was best.
---
Robert Treat wrote:
On Thu, 2003-06-05 at 11:23, Josh Berkus wrote:
4) Does anyone else have any comments on the proposed re-ordering?
I think this was touched on before, but was there a final determination
of the ordering of the show all command? I'm hoping that will return
in the new order of the postgresql.conf
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
[HACKERS] 7.3.3 COMPILE FAILURE: pg_dump
cc -O -g -I../../../src/interfaces/libpq -I../../../src/include -I/usr/local/include -DBINDIR=\/usr/local/pgsql/bin\ -c -o pg_dump.o pg_dump.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled UX:acomp: ERROR: pg_dump.c, line 192: incomplete struct/union/enum option: long_options UX:acomp: ERROR: pg_dump.c, line 193: too many struct/union initializers UX:acomp: ERROR: pg_dump.c, line 193: cannot recover from previous errors gmake[3]: *** [pg_dump.o] Error 1 gmake[3]: Leaving directory `/home/ler/pg-dev/postgresql-7.3.3/src/bin/pg_dump' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/ler/pg-dev/postgresql-7.3.3/src/bin' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/home/ler/pg-dev/postgresql-7.3.3/src' gmake: *** [all] Error 2 $ on UnixWare 7.1.3 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] large objects
Repost just to add the information that this is [now] on 7.3.3, previously on 7.3.2. Sorry for the noise of the incomplete previous message, although the email lists seem to be very light this last week. Obviously the mail server is still feeling under the weather, I presume many posts have been lost in a hole somewhere much like another of my posts. On Sun, 8 Jun 2003, Nigel J. Andrews wrote: Note, primary list address changed to -general, I'd suggest any followups remove the -hackers, which I've left in just for 'closure'. On Fri, 6 Jun 2003, Nigel J. Andrews wrote: On Fri, 6 Jun 2003, Tom Lane wrote: Nigel J. Andrews [EMAIL PROTECTED] writes: Now, I did a little bit of testing and when doing a \lo_export oid filename in psql connected via localhost a SIGPIPE is generated in write() in libc and psql quit, without printing any message to the terminal. Perhaps interestingly the file that gets written is always 65536 bytes long. Hm. Are you using an SSL connection? There are some known bugs in the SSL support in 7.3.1. It's supposed to be fixed in 7.3.3, though I've not tried it myself. Damn, yes I am, I noticed the notice when connecting but then didn't think anything of it. Thanks Tom, I'll check that later when I do have time (shouldn't have wasted the precious minutes joining the NULL != war). Ok, I tried to try this but I can not get SSL to _not_ be used when connecting via any tcp connection, unless the client hasn't been built with ssl support of course. The pg_hba.conf has: # TYPE DATABASEUSERIP-ADDRESSIP-MASK METHOD local all all md5 host all all 127.0.0.1 255.255.255.255 md5 psql -U me -h localhost db prints: SSL connection (cipher: EDH-RSA-DES-CBC3-SHA, bits: 168) psql -U me db doesn't. Am I losing my mind? Should I need hostssl on that second line of the config before ssl is allowed? I did look at that code once a few weeks ago and vaguely remember something about host and hostssl handling but can't remember the details. Is this really a bug, even if only in the documentation, or have I got completely the wrong end of the stick? -- Nigel J. Andrews ---(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] Debugging tool for viewing parse trees?
Eric D Nielsen [EMAIL PROTECTED] writes: I've gotten back to working on the SQL99 version of updateable views and I'ld like to confirm my current understanding of the parse tree data structure. Is there a debugging-type tool for outputting the parse tree for a given query? See debug_print_parse, debug_print_rewritten, debug_print_plan, debug_pretty_print GUC variables. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] large objects
Note, primary list address changed to -general, I'd suggest any followups remove the -hackers, which I've left in just for 'closure'. On Fri, 6 Jun 2003, Nigel J. Andrews wrote: On Fri, 6 Jun 2003, Tom Lane wrote: Nigel J. Andrews [EMAIL PROTECTED] writes: Now, I did a little bit of testing and when doing a \lo_export oid filename in psql connected via localhost a SIGPIPE is generated in write() in libc and psql quit, without printing any message to the terminal. Perhaps interestingly the file that gets written is always 65536 bytes long. Hm. Are you using an SSL connection? There are some known bugs in the SSL support in 7.3.1. It's supposed to be fixed in 7.3.3, though I've not tried it myself. Damn, yes I am, I noticed the notice when connecting but then didn't think anything of it. Thanks Tom, I'll check that later when I do have time (shouldn't have wasted the precious minutes joining the NULL != war). Ok, I tried to try this but I can not get SSL to _not_ be used when connecting via any tcp connection, unless the client hasn't been built with ssl support of course. The pg_hba.conf has: # TYPE DATABASEUSERIP-ADDRESSIP-MASK METHOD local all all md5 host all all 127.0.0.1 255.255.255.255 md5 psql -U me -h localhost db prints: SSL connection (cipher: EDH-RSA-DES-CBC3-SHA, bits: 168) psql -U me db doesn't. Am I losing my mind? Should I need hostssl on that second line of the config before ssl is allowed? I did look at that code once a few weeks ago and vaguely remember something about host and hostssl handling but can't remember the details. Is this really a bug, even if only in the documentation, or have I got completely the wrong end of the stick? -- Nigel J. Andrews ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
Josh Berkus [EMAIL PROTECTED] writes: wal_debug is seldom used outside of Postgresql source development or unusual system failures, and should therefore go last. BTW, it occurs to me that wal_debug is one of the hacker-only variables that probably ought not be documented at all. I cannot imagine any use for it for the average DBA. 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] cvs ETA?
?? cvs itself has been working for ages now ... anoncvs isn't ... or is that what you are using? On Thu, 5 Jun 2003, Dave Cramer wrote: Is there any ETA for cvs? Dave -- Dave Cramer [EMAIL PROTECTED] fastcrypt ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] FROM ONLY limitation in RICs
Does the SQL(99?) spec specify that referential integrity checks should have the FROM ONLY limitation? I ask because(afiak; I've googled and such, only found 92 which apparently does not specify anything about inheritance.) I have no access to the specs without spending money that needs to go other places.. I have a hierarchy of tables that reference base tables that may never have insertions, but its children do, which of course creates the problem of broken referential integrity checks due to FROM ONLY. Of course I know I can edit the source, but I figured I'd see if this is specified in the spec, and hopefully induce a change if it isn't. Thanks for you time, James btw, I'm not on the list(yet, perhaps), so please CC me. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] security flaw
Hi all, I wonder if it's a security problem: One of my customer noticed that he could see all databases on the system with phppgadmin. not only he sees databases but tables, views, fonctions... Fortunatly he can't see any row. This customer has the ability to create databases but not users. I wonder if the super_user privilege should be separated from the priviledge of creating databases/users. I alose think that only a superuser should list databases and objects. What do you think? Regards -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
I think people thought if you were doing SHOW ALL, you were looking for
a specific variable, so alphabetical was best.
---
Robert Treat wrote:
On Thu, 2003-06-05 at 11:23, Josh Berkus wrote:
4) Does anyone else have any comments on the proposed re-ordering?
I think this was touched on before, but was there a final determination
of the ordering of the show all command? I'm hoping that will return
in the new order of the postgresql.conf
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(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 6: Have you searched our list archives?
http://archives.postgresql.org
