[PATCHES] costly foreign key ri checks (4)
Dear patchers, Following the discussion about previous versions of this patch, please find attached a new patch candidate for warning about costly foreign key referential integrity checks. 1/ it generates a WARNING 2/ it DETAILs the attributes and types 3/ some regression tests are also appended to foreign_key.sql It validates for me against current head. Have a nice day, -- Fabien Coelho - [EMAIL PROTECTED] costly_ri_notice.patch.gz Description: Binary data ---(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
Re: [PATCHES] minor doc work
Neil Conway wrote: If commandSET/ is allowed, it overrides all other sources of ! values for the parameter. Superusers are allowed to ! commandSET/ more values than ordinary users. Some parameters ! cannot be commandSET/command even by superusers: for example, Please don't use marked up command names as verbs. Next week you'll be commandUPDATE/commanding or something. Here, there is no chance for confusion, so just write cannot be set or cannot be changed with commandSET/command. In fact, the latter is even clearer. ! if they control behavior that cannot reasonably be changed without ! restarting productnamePostgreSQL/productname. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[PATCHES] PSQLRC environment variable.
In the tradition of telnet, xinit, and others, I've created a patch which
allows users to override the location of .psqlrc by setting the PSQLRC
environment variable. I occurs to me that you have probably considered this
and the fact that it is not implemented suggests that you have rejected the
idea, but I needed it and I figured it couldn't hurt to pass it along.
PSQLRC overrides $HOME/.psqlrc and, as with $HOME/.psqlrc, if there is an
error accessing the file, the function just returns having done nothing.
Cheers,
/jtt
[EMAIL PROTECTED]
Index: startup.c
===
RCS file: /src/cvs/postgres/src/bin/psql/startup.c,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 startup.c
--- startup.c 16 Dec 2003 22:15:32 - 1.1.1.4
+++ startup.c 7 Mar 2004 15:15:54 -
@@ -561,7 +561,12 @@
#ifdef WIN32
#define R_OK 0
#endif
-
+ if ((psqlrc = getenv(PSQLRC)))
+ {
+ if (access(psqlrc, R_OK) == 0)
+ process_file(psqlrc);
+ return;
+ }
/* Look for one in the home dir */
home = getenv(HOME);
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [PATCHES] notice about costly ri checks (2)
As a side question, if there are multiple cross-type conversions in one constraint on different column pairs, what do we think the message should be? One message with multiple column mentions in detail or multiple notices? (I haven't looked at the patch to see if one or the other is easier with how it's set up) I would expect it to generate one WARNING for each mismatch; doing anything else would make life a lot more complex, both as to writing the code and as to formatting the output readably. I agree. patch v1 issued the warning once for each mismatch, in the check loop. patch v2 issued the warning once for the foreign key, outside of the loop. patch v3 is yet to come;-) I'll re-submit a patch some time later, with a WARNING and mismatch column names and types specified. -- Fabien. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] [GENERAL] dblink: rollback transaction
Joe, I applied the patch to 7.4.1 on RH Linux 8.0 and it works great. Thanks. Oleg -Original Message- From: Joe Conway [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 11:12 PM To: [EMAIL PROTECTED] Cc: Tom Lane; Oleg Lebedev Subject: Re: [PATCHES] [GENERAL] dblink: rollback transaction Joe Conway wrote: Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: I like the idea in general, but maybe instead there should be a new overloaded version of the existing function names that accepts an additional bool argument. Without the argument, behavior would be as it is now; with it, you could specify the old or new behavior. Um, maybe I'm confused about the context, but aren't we talking about C function names here? No overloading is possible in C ... I was thinking in terms of overloaded SQL function names. For example, in addition to dblink_exec(text) and dblink_exec(text,text) we create dblink_exec(text,bool) and dblink_exec(text,text,bool). Currently both SQL versions of dblink_exec are implemented by a single C level function. But yes, we'd need another C level function to support the new SQL functions because there would be no way to distinguish the 2 two-argument versions otherwise. (Actually, now I'm wondering if we could use a single C function for all four SQL versions -- between PG_NARGS() and get_fn_expr_argtype() we should be able to figure out how we were called, shouldn't we?) The attached implements the new overloaded SQL functions as discussed above (i.e. start with existing argument combinations, add a new bool argument to each). I ended up with a single C function (by making use of number and type of the arguments) for each overloaded SQL function name. I'll commit in a day or two if there are no objections. Thanks, Joe * This e-mail may contain privileged or confidential material intended for the named recipient only. If you are not the named recipient, delete this message and all attachments. Unauthorized reviewing, copying, printing, disclosing, or otherwise using information in this e-mail is prohibited. We reserve the right to monitor e-mail sent through our network. * ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PATCHES] Alter table Patch
This patch seems to have fallen off of Bruces To be applied list
without being applied. Could I get a status report?
http://archives.postgresql.org/pgsql-patches/2003-11/msg00222.php
--
Rod Taylor rbt [at] rbt [dot] ca
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
PGP Key: http://www.rbt.ca/signature.asc
signature.asc
Description: This is a digitally signed message part
Re: [PATCHES] ALSO keyword to CREATE RULE patch
I thought the syntax came from Berkeley. We can add ALSO if folks like it. I can't think of cases where we have keywords for both on and off behavior, and allow a default if the keyword is missing. ALTER TABLE ... DROP CONSTRAINT ... [ RESTRICT | CASCADE ] CREATE TABLE ... [ WITH OIDS | WITHOUT OIDS ] CREATE USER [ CREATEDB | NOCREATEDB ] ... IMHO, from the language design point of view, it seems better if all options have a name. -- Fabien. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] PSQLRC environment variable.
Seems like a nice feature to me.
---
James Tanis wrote:
In the tradition of telnet, xinit, and others, I've created a patch which
allows users to override the location of .psqlrc by setting the PSQLRC
environment variable. I occurs to me that you have probably considered this
and the fact that it is not implemented suggests that you have rejected the
idea, but I needed it and I figured it couldn't hurt to pass it along.
PSQLRC overrides $HOME/.psqlrc and, as with $HOME/.psqlrc, if there is an
error accessing the file, the function just returns having done nothing.
Cheers,
/jtt
[EMAIL PROTECTED]
Index: startup.c
===
RCS file: /src/cvs/postgres/src/bin/psql/startup.c,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 startup.c
--- startup.c 16 Dec 2003 22:15:32 - 1.1.1.4
+++ startup.c 7 Mar 2004 15:15:54 -
@@ -561,7 +561,12 @@
#ifdef WIN32
#define R_OK 0
#endif
-
+ if ((psqlrc = getenv(PSQLRC)))
+ {
+ if (access(psqlrc, R_OK) == 0)
+ process_file(psqlrc);
+ return;
+ }
/* Look for one in the home dir */
home = getenv(HOME);
---(end of broadcast)---
TIP 8: explain analyze is your friend
--
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/docs/faqs/FAQ.html
Re: [PATCHES] PSQLRC environment variable.
James Tanis [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED], Tom Lane avows: Uh, why is that a good idea? As you will see, it takes a pretty contrived situation, but indeed I've got one :-) I have a software system which can use postgres if the user so wishes. We have a wrapper program for psql which logs in the caller to the database using stored values from another file. I wanted also to be able to set the search path so that everyone wouldn't have to constantly prepend our schema name to our table names in order to view our tables, so that immediatly suggested using .psqlrc. I do *not* however want to override (or overwrite) any .psqlrc they might have, neither do I want to *create* one if they don't have one since we call exec psql at the end of the wrapper and thus cannot clean it up. So if they do not have a $HOME/.psqlrc, I create one in a tmp directory inside of the directory tree where our software lives and set PSQLRC to point at it. It doesn't matter that we can't clean it up because it lives in our space (as it were). But if they do have their own .psqlrc, doesn't that mean that you fail to apply the change you need? It seems like this mechanism doesn't achieve the results you actually want. Wouldn't setting search_path via PGOPTIONS be as effective if not more so? regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] PSQLRC environment variable.
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Uh, why is that a good idea? Well, suppose you want all your users to use the same psqlrc file. Instead of creating symlinks for every user, you can just set PSQLRC in /etc/profile and everyone gets it. ... but people who want to make their own .psqlrc can't? At least not till it occurs to them to unset PSQLRC? I don't really see the use-case here. James' stated problem of setting a default search_path could be handled at least as effectively through either PGOPTIONS or server-side GUC settings (postgresql.conf, or per-user or per-database variable settings). I'm not averse to inventing PSQLRC if there's actually some case it solves better than any of our existing mechanisms. But so far it seems like a solution desperately in search of a problem. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Initial Review of Copy Command Patch
mike g [EMAIL PROTECTED] writes: I thought I would try and knock off the count number of rows inserted when using the Copy command from the todo list. I think what was envisioned was adding a field to the COPY command tag returned at command completion. Sending an INFO message seems way too noisy... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
