Re: [GENERAL] Temporary tables and miscellaneous schemas
Why wouldn't you want to hide pg_temp_*? So you could see your own temp tables, for instance. I dislike putting random restrictions on what the \d displays will show. We have done this in the past (eg, \df doesn't show things it thinks are I/O functions) and by and large it's been a mistake; I think it's created more confusion than it's prevented. I certainly don't think there is any justification for exposing pg_toast if we are going to hide other system schemas. There is no normal reason for needing to access toast tables directly, and it's only an implementation artifact that they have names at all. Hrm... psql's unfortunately an SQL interface to PostgreSQL and an administration tool. What would you say to adding a -P switch (power user) to psql that'd disable any information hiding: the default would be to hide non-critical areas including pg_catalog, pg_toast, template1, and template0. \set POWERUSER would also work to toggle this.. or just have \P toggle this mode. Thoughts? -sc -- Sean Chittenden ---(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: [GENERAL] Temporary tables and miscellaneous schemas
Sean Chittenden [EMAIL PROTECTED] writes: I dislike putting random restrictions on what the \d displays will show. We have done this in the past (eg, \df doesn't show things it thinks are I/O functions) and by and large it's been a mistake; I think it's created more confusion than it's prevented. Hrm... psql's unfortunately an SQL interface to PostgreSQL and an administration tool. What would you say to adding a -P switch (power user) to psql that'd disable any information hiding: the default would be to hide non-critical areas including pg_catalog, pg_toast, template1, and template0. \set POWERUSER would also work to toggle this.. or just have \P toggle this mode. Thoughts? I don't think that really answers my concern, since the sort of folks who are likely to get confused by not being able to see something that should be there are exactly the same ones who are not likely to have turned on a non-default power user setting. If anything, adding such a setting is likely to increase confusion rather than decrease it, because people will get accustomed to differing results. I'm not dead set on this, and will concede gracefully if there's a consensus that we should change \dn's behavior. I'm just trying to make the point that it's a decision with pluses and minuses, not a no-brainer improvement. Anyone else out there have an opinion? regards, tom lane ---(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: [GENERAL] Temporary tables and miscellaneous schemas
I dislike putting random restrictions on what the \d displays will show. We have done this in the past (eg, \df doesn't show things it thinks are I/O functions) and by and large it's been a mistake; I think it's created more confusion than it's prevented. Hrm... psql's unfortunately an SQL interface to PostgreSQL and an administration tool. What would you say to adding a -P switch (power user) to psql that'd disable any information hiding: the default would be to hide non-critical areas including pg_catalog, pg_toast, template1, and template0. \set POWERUSER would also work to toggle this.. or just have \P toggle this mode. Thoughts? I don't think that really answers my concern, since the sort of folks who are likely to get confused by not being able to see something that should be there are exactly the same ones who are not likely to have turned on a non-default power user setting. If anything, adding such a setting is likely to increase confusion rather than decrease it, because people will get accustomed to differing results. Or overwhelmed by bits that they shouldn't be exposed to... I'm not dead set on this, and will concede gracefully if there's a consensus that we should change \dn's behavior. I'm just trying to make the point that it's a decision with pluses and minuses, not a no-brainer improvement. *nods* Though I do think that masking pg_temp_* would be useful as I've never seen a need to look inside of a pg_temp_* schema. Someone running with -E would quickly pick up that pg_temp_* is filtered from the results. I have a machine with over 1K persistent connections and over 1K pg_temp_* entries... I've been running with the patch submitted earlier and it cuts down on the visual noise/unnecessary info considerably. Switching between DBA mode and a data consumer with \P sounds pretty appealing to me and would be something I'd be interested in doing the leg work for. Changing the prompt would probably be good from a UI perspective and adding the necessary logic so that if the connecting user had DBA privs, it'd run in a power user mode instead of the normal data consumer mode. -sc -- Sean Chittenden ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[GENERAL] Pgsql on Windows
How soon will 7.5 come out? (yes, I know, 7.4 is beta right now). How difficult is it to set up cygwin? I'd like to make a drop in Apache/Postgres/PHP application on a windows computer for someone in my organization. I'd PREFER to avoid ODBC if at all possible. ---(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: [GENERAL] Pgsql on Windows
On Mon, 2003-10-13 at 17:10, Dennis Gearon wrote: How soon will 7.5 come out? (yes, I know, 7.4 is beta right now). Who knows... six months maybe? How difficult is it to set up cygwin? Not very, I used postgres via cygwin for development for a long time. Works fine, but it's slower and not quite as stable as you would want for production purposes. I'd like to make a drop in Apache/Postgres/PHP application on a windows computer for someone in my organization. I'd PREFER to avoid ODBC if at all possible. I don't see how ODBC fits in to this at all. There is no need for ODBC if postgresql is running via cygwin, running on a remote linux box, or even native on windows. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] log_duration and \timing times repeatably much higher
Alvaro Herrera [EMAIL PROTECTED] writes: Looking at explain.c, it is only timing the executor part in ExplainOnePlan(). The planner() call is outside that loop, so it must be parse/plan, though that seems like a lot of time spent in that area. As I posted separately that seems to be exactly where the time is being spent. It take nearly a second simply for a plain old explain with no analyze. Could it be because of extremely large statistics settings for the tables involved? Which large statistics? Does he more than the default number of statistics buckets? I dunno, that's why I'm asking :-) Just an idea. This sounds like a good theory to me. But I can't find anything like that. Perhaps some large statistic array being toasted and compressed? What would I check for? Just looking in pg_statistic doesn't find anything that stands out. The strangest lines to my eyes are the ones with the verbose plan stuff in them, but there are similar lines on my working machine. Is there any way to see what the values are set with ALTER TABLE ALTER column SET STATISTICS ? Perhaps it should be listed in the \d output for the table? -- greg ---(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: [GENERAL] Pgsql on Windows
Dennis Gearon writes: How soon will 7.5 come out? (yes, I know, 7.4 is beta right now). All signs point to September 24, 2004. How difficult is it to set up cygwin? I found it quite easy. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Pgsql on Windows
Matthew T. O'Connor wrote: I don't see how ODBC fits in to this at all. There is no need for ODBC if postgresql is running via cygwin, running on a remote linux box, or even native on windows. I am new to PostgreSQL what other options are available to connect then ? -- Eugene Vital Any technology indistinguishable from magic is insufficiently advanced. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Pgsql on Windows
Peter Eisentraut wrote: Dennis Gearon writes: How soon will 7.5 come out? (yes, I know, 7.4 is beta right now). All signs point to September 24, 2004. Have you verified that with the Master of Ceremonies? Mike Mascari [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] Slow SELECT
Mat [EMAIL PROTECTED] writes: On Fri, 2003-10-03 at 17:50, Tom Lane wrote: Well, it seems to be running at about 5 msec/row, which would be quite respectable if each fetch required another disk seek. I'm wondering why you are (apparently) not managing to get more than one row per page fetched. What are your configuration settings --- particularly shared_buffers? Could we see the output of VACUUM VERBOSE for this table? Lines from postgresql.conf that don't start with a '#': shared_buffers = 126976 #992 MB As someone else pointed out, that is way too large (unless maybe you have 4Gb of RAM, and even then I'd not counsel making shared_buffers that large). INFO: --Relation public.meta-- INFO: Pages 685043: Changed 0, Empty 8; Tup 5999170: Vac 0, Keep 0, UnUsed 5999170. Total CPU 18.06s/3.61u sec elapsed 612.91 sec. This shows you've got less than 9 tuples per 8k disk page on average. Is the table very wide? If it doesn't seem to you that the tuples should occupy 1K apiece, it might be that you need to run a VACUUM FULL to get rid of some excess free space. (If so, it's a sign that you need to increase the FSM settings in postgresql.conf and/or run plain VACUUM more frequently, so that the free space doesn't get away from you again.) regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] libreadline.so.4 problems on solaris
El Lun 13 Oct 2003 11:38, Tom Lane escribió: Alex [EMAIL PROTECTED] writes: The LD_LIBRARY_PATH actually points to the library, I am even able to execute the initdb but the postmaster always fails In that case, almost certainly, the environment you are starting the postmaster in is different from the one you ran initdb in (no LD_LIBRARY_PATH setting, probably). Better check where LD_LIBRARY_PATH is set and how that setting will propagate to the postmaster. Listen carfully to what Tom says, cuase he helped me with this same problem in the past! :-) What I did was put in the /etc/init.d/postgresql file, at the line that starts the postmaster (executing the postamaster directly or running pg_ctl) the longer LD_LIBRARY_PATH. Something like this: echo -n Starting postgresql service: su - postgres -c export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib; /dbs/postgres/bin/pg_ctl -o \-o -e\ -D /dbs/postgres/data/ start /dev/null Sorry for the lines that got cut. :-( -- Porqué usar una base de datos relacional cualquiera, si podés usar PostgreSQL? - Martín Marqués |[EMAIL PROTECTED] Programador, Administrador, DBA | Centro de Telemática Universidad Nacional del Litoral - ---(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
[GENERAL] gborg cvs ?
Is something up with gborg cvs, or have the settings changed? % cvs update cvs [update aborted]: connect to gborg.postgresql.org:2401 failed: Connection timed out % cat CVS/Root :pserver:[EMAIL PROTECTED]:/usr/local/cvsroot/libpqxx % cat CVS/Repository libpqxx Cheers, Patrick ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] Pgsql on Windows
On Mon, 2003-10-13 at 17:37, Gene Vital wrote: Matthew T. O'Connor wrote: I don't see how ODBC fits in to this at all. There is no need for ODBC if postgresql is running via cygwin, running on a remote linux box, or even native on windows. I am new to PostgreSQL what other options are available to connect then ? When you have postgresql support compiled into PHP, then PHP connects directly using native PostgreSQL calls (libpq), no ODBC layer to deal with. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] Pgsql on Windows
Hi When you have postgresql support compiled into PHP, then PHP connects directly using native PostgreSQL calls (libpq), no ODBC layer to deal with. Working with Windows you normally don't compile PHP but use the Win binaries. To connect to a PostgreSQL database you must uncomment the php_pgsql.dll in php.ini. Regards Conni ---(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: [GENERAL] gborg cvs ?
Patrick Welche [EMAIL PROTECTED] writes: Is something up with gborg cvs, or have the settings changed? Works here. Probably your DNS server still has the old IP address cached. All the Postgres servers were moved to new IP addresses today. 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: [GENERAL] A conditional DROP TABLE function
Hi Tino, --- Tino Wildenhain [EMAIL PROTECTED] wrote: David Link wrote: Hi All, Here's a Conditional drop_table func for those interested. There was a thread on this a long time back. We do this all the time : DELETE TABLE sales; CREATE TABLE sales (...); Hm. all the time enables all the warning lights - what are you doing to have to delete and create the tables every time? By 'all the time' i mean once a week. (incidently, it is DROP and not DELETE table, of course). We are working with weekly loads of data. because of the volumns i'm using a separate sales table per week, (ie, sale_200301, sale_200302, etc), becuase when it was in one big happy table (ie, sale) it is slower -- especially recreating indexes. Now you can see, to make the weekly data load process rerunnable (and we do rerun it often) i drop and [re]create this weeks collection of sales related tables. The logs contain statistics, warnings and errors, which we share with the non-geeks who use the data. Also, standard procedure (I believe) for maintaining a data model is creating and using database creation scripts (with DROP and CREATE) - so every time you set up a bran new system, you can get those (i believe) unnecessary messages: ERROR table does not exist. -Thanks. But nobody likes ERROR: table sales does not exist which we see all the time in the logs. I want to show the logs to none db folk -- so we can't have those error messages in it. grep -v ERROR should do it. Yes, but then you've got to wrap things in a log filter to generate reports rather than just using the processing log as it comes out. (There must be some explaination why postgresql (and Oracle as well) do not have CREATE OR REPLACE TABLE as it does for VIEWs, and FUNCTIONs. Anybody know?) Nobody needs this? There is: 1) delete from table; 2) truncate table; to remove all the data 3) alter table ... to change tables layout. these do not create the table should it not yet exist. and i needed it. -- so i wrote the simple stored procedure to make meself happy. i noticed others have asked for a solution to the problem as well. (are you being a stickler?) also in the name of consistency, CREATE OR REPLACE exist for stored procedures (and views?). PS: I LOVE Postegres. It has made my life (as an Oracle DBA) charming rather than hell! Thanks. HTH Tino Wildenhain __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ---(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: [GENERAL] int1?
Sean Chittenden [EMAIL PROTECTED] writes: If we were going to do that I think we'd be better off making a new type and leaving char alone. You won't hear any disagreements from me on this one. I've sufficiently abused char as a 1 byte storage field and would love to see an int1 or tinyint datatype added to cover this situation. -sc That's been discussed before. I think it was shelved until we figure out a reasonably clean solution to the existing mess with assigning the most useful datatypes to integer constants (the you need to cast set of problems). Throwing an additional integer type into the stew right now would just make things worse :-( regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] Locale bug?
Sergey Suleymanov [EMAIL PROTECTED] writes: ... That is upper() doesn't work correctly after plperlu function call. It sounds like Perl is taking it on itself to change the process' LC_CTYPE settings. That's very nasty of it :-(. Can anyone confirm that libperl does such things, or find a workaround to prevent it? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Temporary tables and miscellaneous schemas
Sean Chittenden wrote: I don't think that really answers my concern, since the sort of folks who are likely to get confused by not being able to see something that should be there are exactly the same ones who are not likely to have turned on a non-default power user setting. If anything, adding such a setting is likely to increase confusion rather than decrease it, because people will get accustomed to differing results. Or overwhelmed by bits that they shouldn't be exposed to... I'm not dead set on this, and will concede gracefully if there's a consensus that we should change \dn's behavior. I'm just trying to make the point that it's a decision with pluses and minuses, not a no-brainer improvement. *nods* Though I do think that masking pg_temp_* would be useful as I've never seen a need to look inside of a pg_temp_* schema. Someone running with -E would quickly pick up that pg_temp_* is filtered from the results. I have a machine with over 1K persistent connections and over 1K pg_temp_* entries... I've been running with the patch submitted earlier and it cuts down on the visual noise/unnecessary info considerably. Switching between DBA mode and a data consumer with \P sounds pretty appealing to me and would be something I'd be interested in doing the leg work for. Changing the prompt would probably be good from a UI perspective and adding the necessary logic so that if the connecting user had DBA privs, it'd run in a power user mode instead of the normal data consumer mode. If you see a pg_temp_* for every connection, that is a little overwhelming. pg_toast and stuff aren't really too bad. Is there any way to access your local temp schema in a way that doesn't show the others? Could we use backend_pid in the query and show them only their own? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Does postgresql support HKSCS ?
Gordon Luk [EMAIL PROTECTED] writes:
Yes, HKSCS just an extension of Big5, if pgsql could support natively,
that is lovely. :-{}
Presumably you could extend the existing big5 support, then. See
src/backend/utils/mb/conversion_procs/utf8_and_big5/
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Humor me: Postgresql vs. MySql (esp. licensing)
Vivek Khera [EMAIL PROTECTED] writes: I think it is a timing issue. The PG has no way to notify the OS that it has finished exiting, so if it takes a long time to exit, the OS will ungracefully kill the DB process(es). Doesn't matter what DB (or any other application) you're running, you *can* lose data this way. You most certainly will *not* lose data that way. Committed transactions will stay committed, no matter how the Postgres processes die. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[GENERAL] SET within a function?
Hi all! I am doing some trigger functions that need to find a tuple in another table. The problem is that this second table is doing some summarization work, and I need nulls to equal each other. Basically, in the trigger I do a: SELECT INTO ... x FROM table1 WHERE ...(some straightforward x = old.x)... AND (x1 = old.x1 OR (x1 is null and old.x1 is null)) AND (x2 = old.x2 OR (x2 is null and old.x2 is null)) AND (x3 = old.x3 OR (x3 is null and old.x3 is null)); The problem is that an index is used to perform the straightforward stuff, and then the x1,x2,x3 is done via an index scan, rather than directly. Unfortunately for the data set I have, it can be clustered pretty badly around the straightforward stuff, and so the scan can take multiple seconds per call. I think if I could do a 'SET TRANSFORM_NULL_EQUALS TO ON' then this might fix the issue (don't know, haven't tried it yet). My question is: can this be done within a function such that at the end of the function, the value is reset back to value upon entering (kind of like 'SET LOCAL' except for just the length of the function call). Is this possible? Thanks! Ed ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] [INTERFACES] more on undefined reference to 'pg_detoast_datum'
Tom Lane wrote: D. Stimits writes: ... My question is, where the heck is CurrentMemoryContext and MemoryContextAlloc provided as an implementation which I can link with? They're inside the backend, and you don't --- you are not trying to build a standalone executable with no unresolved symbols, but a shared library that can be successfully loaded into the backend. It's okay for such a library to have unresolved references to symbols that will be resolved at load time. regards, tom lane Thanks to all that answered this. I found the problem, and it was totally unexpected. There were some leftover Makefile lines that were used to build a standalone module loader test unit, that test unit does not implement palloc. The actual dynamic loadable module was in fact working right, but the make was dying early when it so much as referenced the old module loader code (a loader used to test/regress functions before trying it on a server). I couldn't believe my eyes when I saw those old lines in there. D. Stimits ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Index on timestamp to date field
On Mon, Oct 13, 2003 at 13:49:07 -0700, Patrick Hatcher [EMAIL PROTECTED] wrote: I have a timestamp field where I find I'm doing a lot of searching by date (-MM-DD) or using this field as a match to another table that has a date format. I wanted to create an index on the timestamp field using a date format. Is this possible? I tried: CREATE INDEX test_2 ON table1 USING btree to_char(field2, 'MM-DD-'); but I get an error message error at or new to_char You can't create general functional indexes until 7.4. However you might be able to use an index on the timestamp if you cast the character strings to a timestamp value. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] SET within a function?
On Mon, Oct 13, 2003 at 21:16:33 -0400, Edmund Dengler [EMAIL PROTECTED] wrote: I think if I could do a 'SET TRANSFORM_NULL_EQUALS TO ON' then this might fix the issue (don't know, haven't tried it yet). My question is: can this be done within a function such that at the end of the function, the value is reset back to value upon entering (kind of like 'SET LOCAL' except for just the length of the function call). Is this possible? I don't think that will do what you want. That setting is used to rewrite = null as is null, not to change things so that nulls match each other. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] gborg cvs ?
Name:svr3.postgresql.org Address: 200.46.204.161 Aliases: gborg.postgresql.org On Mon, 13 Oct 2003, Patrick Welche wrote: Is something up with gborg cvs, or have the settings changed? % cvs update cvs [update aborted]: connect to gborg.postgresql.org:2401 failed: Connection timed out % cat CVS/Root :pserver:[EMAIL PROTECTED]:/usr/local/cvsroot/libpqxx % cat CVS/Repository libpqxx Cheers, Patrick ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] SET within a function?
Is the rewrite only for the literal 'X = NULL' or will it do a test against a value such as 'X = OLD.X' (and rewrite is OLD.X is NULL)? Is there any way to match NULLS to each other (as I am looking for a literal row, not using NULL as the UNKNOWN). I suppose I could put in a dummy value for the 'Not a valid value', but it seems to be quite awkward when I really do want the NULL. Regards! Ed On Mon, 13 Oct 2003, Bruno Wolff III wrote: On Mon, Oct 13, 2003 at 21:16:33 -0400, Edmund Dengler [EMAIL PROTECTED] wrote: I think if I could do a 'SET TRANSFORM_NULL_EQUALS TO ON' then this might fix the issue (don't know, haven't tried it yet). My question is: can this be done within a function such that at the end of the function, the value is reset back to value upon entering (kind of like 'SET LOCAL' except for just the length of the function call). Is this possible? I don't think that will do what you want. That setting is used to rewrite = null as is null, not to change things so that nulls match each other. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[GENERAL] spam or crazy mail server changes?
I'm still getting lots of SMTP hits from varying servers attempting to deliver mail to my tagged email address, used only for subscribing to this list. The delivery attempts are using the same envelope sender address style as is used by the list itself. But is this real mailing list attempts from a messed up server or network, or is it a slick spammer doing a smooth job of faking the mailing list in every way but a validated reverse DNS? I have postgresql.org whitelisted, so mail delivery from a mail server that has a reverse DNS of a name that contains the peer address among its A records will succeed. Any address with no reverse DNS, or has reverse DNS that does not validate, and is from an IP address that is not whitelisted, will fail. Other addresses may or may not fail, depending on other information. If these attempts are really a spammer desperately trying to send me several messages a day, I'll take it up with the hosting ISPs. But if it is another mail server for this list that isn't set up right (as defined by what it takes in a spam filled world to rise above the spam), I may just have to leave this list and move on. It's just not practical to keep whitelisting new IP addresses every week. -- - | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ | | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ | - ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] Locale bug?
Tom Lane writes: ... That is upper() doesn't work correctly after plperlu function call. Tom It sounds like Perl is taking it on itself to change the Tom process' LC_CTYPE settings. That's very nasty of it :-(. Can Tom anyone confirm that libperl does such things, or find a Tom workaround to prevent it? It seems a startup script issue. When I restarting postmaster manualy (within root session with LC_CTYPE = ru_RU.KOI8-R) everything works fine. Do we need export LANG=... before starting postmaster? -- Sergey Suleymanov ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] spam or crazy mail server changes?
Phil Howard [EMAIL PROTECTED] writes: I'm still getting lots of SMTP hits from varying servers attempting to deliver mail to my tagged email address, used only for subscribing to this list. The postgresql.org servers were moved to new IP addresses today. It looks like the reverse DNS mapping hasn't caught up yet. Marc? regards, tom lane ---(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: [GENERAL] SET within a function?
Edmund Dengler wrote: Is the rewrite only for the literal 'X = NULL' or will it do a test against a value such as 'X = OLD.X' (and rewrite is OLD.X is NULL)? It is a parse time transformation: http://groups.google.com/groups?hl=enlr=ie=UTF-8oe=UTF-8frame=rightth=26ef31219ae11442seekm=3DF52206.5060507%40mascari.com#link6 Is there any way to match NULLS to each other (as I am looking for a literal row, not using NULL as the UNKNOWN). I suppose I could put in a dummy value for the 'Not a valid value', but it seems to be quite awkward when I really do want the NULL. Normalization would have you eliminate the NULL by having another relation whose candidate key is the same as your original table, but those records whose attribute is NULL would simply not be present in the child table. Another possible solution is to define your own type with an internal status for 'Not a valid value'... HTH, Mike Mascari [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])
