[HACKERS] HISTORY updated, 7.3 branded
OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1. I used the same HISTORY categories Peter made in 7.2. I liked them. Please review the HISTORY file. I am sure there are improvements that can be made. -- 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/users-lounge/docs/faq.html
Re: [HACKERS] HISTORY updated, 7.3 branded
On 4 Sep 2002 at 3:24, Bruce Momjian wrote: > OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1. > > I used the same HISTORY categories Peter made in 7.2. I liked them. > > Please review the HISTORY file. I am sure there are improvements that > can be made. Some minor stuff, 1) Line 74/Line 20 are same. Since they are in notes for different releases, I suspect one of them has to move. 2)Line 61 cash I/O improvements (Tom) Is that 'cash' is correct(cache?)? Sorry, if I have missed earlier threads on this. The file I am looking at is last updated on Aug. 25. (anoncvs.postgresql.org). I will update once again in an hour and check again.. Bye Shridhar -- There's nothing disgusting about it [the Companion]. It's just anotherlife form, that's all. You get used to those things.-- McCoy, "Metamorphosis", stardate 3219.8 ---(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] HISTORY updated, 7.3 branded
I assume you are not looking at the 7.3 release notes. It does take a while for anon to get the changes. --- Shridhar Daithankar wrote: > On 4 Sep 2002 at 3:24, Bruce Momjian wrote: > > > OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1. > > > > I used the same HISTORY categories Peter made in 7.2. I liked them. > > > > Please review the HISTORY file. I am sure there are improvements that > > can be made. > > Some minor stuff, > > 1) Line 74/Line 20 are same. Since they are in notes for different releases, I > suspect one of them has to move. > > 2)Line 61 > cash I/O improvements (Tom) > > Is that 'cash' is correct(cache?)? > > Sorry, if I have missed earlier threads on this. The file I am looking at is > last updated on Aug. 25. (anoncvs.postgresql.org). > > I will update once again in an hour and check again.. > > Bye > Shridhar > > -- > There's nothing disgusting about it [the Companion]. It's just anotherlife > form, that's all. You get used to those things. -- McCoy, >"Metamorphosis", > stardate 3219.8 > > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > -- 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
[HACKERS] What is Tid Scan
Hello everyone. I can't understand Tid Scan, Who can tell me what it's that and where I could find document on the Web. Thanks for your reponse. Guo longjiang Harbin China __ === ÐÂÀËÃâ·Ñµç×ÓÓÊÏä (http://mail.sina.com.cn) ÐÂÀË·ÖÀàÐÅÏ¢£º¶þÊÖÊг¡×ßÒ»×ߣ¬¸Ã³öÊÖʱ¾Í³öÊÖ£¡ (http://classad.sina.com.cn/2shou/) ÊýÍòÕÅÊÖ»úͼƬÊýÍòÊ׶ÌÐÅÁåÉùÈÎÄãÌôÑ¡£¬Ã¿Ì춼ÓиüР(http://sms.sina.com.cn/cgi-bin/sms/smspic.cgi) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS]
Hello, Mr. Tom Lane I am a chinese student studied in Harbin institute of technology. I want join to PostgreSQL Global Development Group and I want work on the planner/optimizer. I have been reading the source code for 2 months. There many data strucutres I can't understand. Can you tell me what document I must read first. If you have documents about planner/optimizer of PostgreSQL, send me please. a doctor student English name is Mohan. Chinese name is Guo long jiang. Thank you very much! 04/09/2002 __ === ÐÂÀËÃâ·Ñµç×ÓÓÊÏä (http://mail.sina.com.cn) ÐÂÀË·ÖÀàÐÅÏ¢£º¶þÊÖÊг¡×ßÒ»×ߣ¬¸Ã³öÊÖʱ¾Í³öÊÖ£¡ (http://classad.sina.com.cn/2shou/) ÊýÍòÕÅÊÖ»úͼƬÊýÍòÊ׶ÌÐÅÁåÉùÈÎÄãÌôÑ¡£¬Ã¿Ì춼ÓиüР(http://sms.sina.com.cn/cgi-bin/sms/smspic.cgi) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] HISTORY updated, 7.3 branded
> OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1. > > I used the same HISTORY categories Peter made in 7.2. I liked them. > > Please review the HISTORY file. I am sure there are improvements that > can be made. Please change: > Add CREATE/DROP CONVERSION, allowing loadable encodings (Tatsuo) To: Add CREATE/DROP CONVERSION, allowing loadable encodings (Tatsuo, Kaori) She provided lots of encodings for CONVERSION. -- Tatsuo Ishii ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Multibyte support in oracle_compat.c
> I found one bug in file src/backend/utils/adt/oracle_compat.c and there were >your name, related with Multibyte enhancement, so i write to you. > Functions upper,lower and initcap doesn't work with utf-8 data which is not of >Latin letters.At my work i do databases for Russian users and when i tried to use >unicode encoding for database and Russsian alphabet than these functions didn't work. >So i wrote some patches, because i don't think that problem is in that or other shell >variable like LANG or LC_CTYPE. As i don't know any other > languages except Russian and English, i wrote small test(test.tar.gz) only for >them.Execute it befor and after patching and feel the difference:). And by the way, >do encodings(and appropriative languages) EUC_JP,EUC_CN,EUC_KR and EUC_TW have >logical operations upper,lower and initcap? > regards,Eugene. For EUC_JP, there is no upper,lower and initcap. I'm not sure about other languages. > P.S.It doesn't seem bad for me to use lib unicode instead of functions like >mbtowc,wctomb from stdlib and towupper,towlower from wctype, but may be somebody will >find decision based on them or other lib? I'm not sure. What do you think, Peter or other guys who is familiar with Unicode? BTW, I don't like your patches. If there's no unicode.h, configure aborts with: configure: error: header file is required for unicode support which seems not acceptable to me. I suggest you #ifdef out the unicode upper,lower and initcap support if libunicode and/or unicode.h are not found in the system. -- Tatsuo Ishii (I have included patches for review purpose) patches.tar.gz Description: Binary data test.tar.gz Description: Binary data ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] HISTORY updated, 7.3 branded
Found this line without a name: Propagate column or table renaming to foreign key constraints Is that item complete? pg_constraint follows (as such dump / restore will work) but the triggers themselves still break, don't they? On Wed, 2002-09-04 at 03:24, Bruce Momjian wrote: > OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1. > > I used the same HISTORY categories Peter made in 7.2. I liked them. > > Please review the HISTORY file. I am sure there are improvements that > can be made. > > -- > 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/users-lounge/docs/faq.html > ---(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] What is Tid Scan
On Wed, 2002-09-04 at 12:43, ljguo_1234 wrote: > Hello everyone. > I can't understand Tid Scan, Who can tell me what it's that and where I could >find document on the Web. Thanks for your reponse. It is scanning table by TupleID's. A tuple id is a 6-byte entity which consists of 4-byte page number and 2-byte tuple index inside page. So if you know the TID you can directly get the corresponding tuple. -- Hannu ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] GBorg is down
Warning: Supplied argument is not a valid PostgreSQL link resource in /usr/local/www/gborg3/html/index.php on line 52 Warning: Supplied argument is not a valid PostgreSQL link resource in /usr/local/www/gborg3/html/include/project.php on line 196 Warning: Supplied argument is not a valid PostgreSQL result resource in /usr/local/www/gborg3/html/include/project.php on line 205 Warning: Supplied argument is not a valid PostgreSQL link resource in /usr/local/www/gborg3/html/include/project.php on line 274 Warning: Supplied argument is not a valid PostgreSQL result resource in /usr/local/www/gborg3/html/include/project.php on line 286 Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] GBorg is down
On Wed, 4 Sep 2002, Christopher Kings-Lynne wrote: > > Warning: Supplied argument is not a valid PostgreSQL link resource in > /usr/local/www/gborg3/html/index.php on line 52 Looks like the machine with the database on it. The mirror update cronjob is failing too. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com == ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] FW: [GWAVA:fku1fb18] Source block message notification
Can anyone find an email in all of that? I did a search of 'afk' ... oops :) got it and removed ... On Wed, 4 Sep 2002, Christopher Kings-Lynne wrote: > Does anyone else get this rubbish when they post to -php ? > > Our domain isn't on any blacklists AFAIK... > > Chris > > > -Original Message- > > From: GWAVA [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, 4 September 2002 11:24 AM > > To: [EMAIL PROTECTED] > > Subject: [GWAVA:fku1fb18] Source block message notification > > > > > > Den postmeddelelse du prøvede at sende til [No To Addresses] blev > > ikke afleveret. > > Meddelelsen kom fra en adresse som ikke tillades i postsystemet > > akf.dk, og blev derfor afvist. > > > > Kontakt venligst din systemadministrator for at få flere > > oplysninger om problemet. > > > > Information om den afviste postmeddelelse: > > > > FRA: [EMAIL PROTECTED] > > TIL: [No To Addresses] > > Emne: Re: [PHP] fastest way to retrieve data > > > > Vedhæftet fil: > > > > The message you tried to send to [No To Addresses] was not delivered. > > The message was sent from an address which is not permitted in > > the akf.dk mail system and was rejected. > > > > Please contact your system administrator for more information. > > > > Information about the problem message: > > > > FROM: [EMAIL PROTECTED] > > TO: [No To Addresses] > > Subject: Re: [PHP] fastest way to retrieve data > > > > Attachment Name: > > > > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] I am done
Gavin Sherry <[EMAIL PROTECTED]> writes: > Does anyone else have an opinion on this? If not, I will implement it per > Bruce's commentary. > On Mon, 2 Sep 2002, Bruce Momjian wrote: >> I think the second, passing an arg to say whether it is server or >> client, will do the trick, though now you need an error one too. I >> guess you have to use #define and set it, or pass a string down with the >> GUC variable and test that with strcmp. I think you're going to end up un-merging the routines. There is no way to pass an extra parameter to the set/check routines (at least not without uglifying all the rest of the GUC code). The design premise is that the per-variable hook routines know what they're supposed to do, and in that case this means one hook for each variable. 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] I am done
Bruce Momjian <[EMAIL PROTECTED]> writes: > Yes, I would like to know if it should be enabled by default, and > whether we need a way to turn it off. I feel it should be off by default --- if enough people say "hey, this is great" then maybe we could turn it on by default, but we don't yet have that market testing to prove the demand is there. I'm also worried about log bloat. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] HISTORY updated, 7.3 branded
Rod Taylor <[EMAIL PROTECTED]> writes: > Found this line without a name: > Propagate column or table renaming to foreign key constraints > Is that item complete? pg_constraint follows (as such dump / restore > will work) but the triggers themselves still break, don't they? Yes, no. There's hackery in tablecmds.c to fix the triggers. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] GBorg is down
should already be fixed ... On Wed, 4 Sep 2002, Vince Vielhaber wrote: > On Wed, 4 Sep 2002, Christopher Kings-Lynne wrote: > > > > > Warning: Supplied argument is not a valid PostgreSQL link resource in > > /usr/local/www/gborg3/html/index.php on line 52 > > Looks like the machine with the database on it. The mirror update > cronjob is failing too. > > Vince. > -- > == > Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net > 56K Nationwide Dialup from $16.00/mo at Pop4 Networking > http://www.camping-usa.com http://www.cloudninegifts.com >http://www.meanstreamradio.com http://www.unknown-artists.com > == > > > > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] webdav interface to pgsql
On Wed, 4 Sep 2002, Christopher Kings-Lynne wrote: > Cool. Is it worth putting it on greatbridge? gborg.postgresql.org greatbridge is back again? *raised eyebrow* ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] HISTORY updated, 7.3 branded
Shridhar Daithankar dijo: > On 4 Sep 2002 at 3:24, Bruce Momjian wrote: > > > OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1. > > Some minor stuff, In the schema changes description: "Schemas allow users to create objects in their own namespace so two people can have the same table with the same name." Shouldn't it read "so two people can have tables with the same name" ? My point is that the tables are not the same, they just have the same name. -- Alvaro Herrera () "Tiene valor aquel que admite que es un cobarde" (Fernandel) ---(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] findoidjoins
Joe Conway <[EMAIL PROTECTED]> writes: > I'm not sure I interpreted the intent of findoidjoins just right, but > here it is updated for schemas, new reg* types, using SPI instead of > libpgeasy, and returning the results as a table function. Any > corrections/comments? For what we want it for (viz, regenerating the oidjoins test every so often), this is really a step backwards. It requires more work to run than the original program, and it modifies the database under test, which is undesirable because it's commonly run against template1. I was thinking of keeping it as a client program, but recasting it to use libpq since libpgeasy isn't in the standard distribution anymore. I've looked through my notes and I can't find why I thought findoidjoins was broken for 7.3. Did you come across anything obviously wrong with its queries? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pgaccess - where to store the own data
On Fri, Aug 30, 2002 at 02:43:38PM -0400, Matthew T. OConnor wrote: > > As someone else mentioned (I think), even using a separate schema is not > > always an acceptable option. If you are using a "packaged" application > > (whether commercial or open source), you usually don't want *any* > > changes to the vendor provided database. Particularly with commercial > > software, that can mean loss of, or problems with, technical support, or > > problems when upgrading. > > Agreed, but if the information is to be stored using the database server at > all, then I think this option should be left in since some users probably > don't mind the clutter, and will not be allowed to create a new database or > schemea. I'm a bit late on this discussion, but I, for one, have liked having some of the pgaccess info stored with the database. That way, no matter what machine I connect to the DB from, I get the same set of functions, queries, and schema-documents. BTW, has the 'schema' tab been renamed yet? With actual schema in 7.3, that'll get confusing. Ross ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Bug in Makefile.shlib
Hi, I think I figured why I can't buil plperl on unixware 711/OpenUnix 800. It seems Makefile.shlib has changed between 722 and 73 and -z text has been added. However with this on, it fails to build libperl.so Maybe I'm wrong, but could someone consider this patch. 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) *** Makefile.shlib mer sep 4 18:13:39 2002 --- Makefile.shlib.orig mer sep 4 18:13:12 2002 *** *** 247,253 LINK.shared = $(CXX) -G endif endif ! LINK.shared += -Wl,-h,$(soname) endif ifeq ($(PORTNAME), win) --- 247,253 LINK.shared = $(CXX) -G endif endif ! LINK.shared += -Wl,-z,text -Wl,-h,$(soname) endif ifeq ($(PORTNAME), win) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] HISTORY updated, 7.3 branded
> Shridhar Daithankar dijo: > > > On 4 Sep 2002 at 3:24, Bruce Momjian wrote: > > > > > OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1. > > > > Some minor stuff, > > In the schema changes description: > > "Schemas allow users to create objects in their own namespace > so two people can have the same table with the same name." > Shouldn't it read "so two people can have tables with the same name" > ? My point is that the tables are not the same, they just have the > same name. How about this for a wording: "Schemas allow users or applications to have their own namespaces in which to create objects. A typical application of this is to allow creation of tables that _appear_ to have the same name. For instance, if some GNOME applications were using PostgreSQL to store their configuration, a "GNUMERIC" namespace might have a table PREFERENCES to store preferences for that application, while a "POWERSHELL" namespace would allow _that_ application to store configuration in a PREFERENCES table that is quite distinct from the "GNUMERIC" one. The "true" table names may be GNUMERIC.PREFERENCES and POWERSHELL.PREFERENCES, but by using Schemas, applications do not need to be speckled with gratuitious added prefixes of GNUMERIC or POWERSHELL." Note that I'm pointing at "applications" as the primary purpose for this, as opposed to "users." In the long run, are not applications more likely to be the driving force encouraging the use of schemas? -- (reverse (concatenate 'string "gro.gultn@" "enworbbc")) http://www3.sympatico.ca/cbbrowne/unix.html "The most precisely-explained and voluminously-documented user interface "rule" can and will be shot to pieces with the introduction of a single new priority consideration." -- Michael Peck ---(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] findoidjoins
Tom Lane wrote: > For what we want it for (viz, regenerating the oidjoins test every so > often), this is really a step backwards. It requires more work to run > than the original program, and it modifies the database under test, > which is undesirable because it's commonly run against template1. > > I was thinking of keeping it as a client program, but recasting it to > use libpq since libpgeasy isn't in the standard distribution anymore. OK. I'll take another shot using that approach. A couple questions: Is it useful to have the reference count and unreferenced counts like currently written, or should I just faithfully reproduce the original behavior (except schema aware queries) using libpq in place of libpgeasy? Is the oidjoins.sql test just the output of the make_oidjoins_check script? It is probably easier to produce that output while looping through the first time versus running a script -- should I do that? > I've looked through my notes and I can't find why I thought findoidjoins > was broken for 7.3. Did you come across anything obviously wrong with > its queries? As written the queries did not know anything about schemas or the newer reg* data types, e.g. this: SELECT typname, relname, a.attname FROM pg_class c, pg_attribute a, pg_type t WHERE a.attnum > 0 AND relkind = 'r' AND (typname = 'oid' OR typname = 'regproc' OR typname = 'regclass' OR typname = 'regtype') AND a.attrelid = c.oid AND a.atttypid = t.oid ORDER BY 2, a.attnum ; became this: SELECT c.relname, (SELECT nspname FROM pg_catalog.pg_namespace n WHERE n.oid = c.relnamespace) AS nspname, a.attname, t.typname FROM pg_catalog.pg_class c, pg_catalog.pg_attribute a, pg_catalog.pg_type t WHERE a.attnum > 0 AND c.relkind = 'r' AND t.typnamespace IN (SELECT n.oid FROM pg_catalog.pg_namespace n WHERE nspname LIKE 'pg\\_%') AND (t.typname = 'oid' OR t.typname LIKE 'reg%') AND a.attrelid = c.oid AND a.atttypid = t.oid ORDER BY nspname, c.relname, a.attnum Does the latter produce the desired result? Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pgaccess - where to store the own data
Ross wrote: > I'm a bit late on this discussion, but I, for one, have liked > having > some of the pgaccess info stored with the database. That way, > no matter > what machine I connect to the DB from, I get the same set of > functions, > queries, and schema-documents. Very much true. A wiki page has been started on that topic - feel free to contribute to the methods and their pros and cons, as well to the proposed final approach. http://www.pgaccess.org/index.php?page=WhereToStoreThePgAccessOwnData > BTW, has the 'schema' tab been renamed yet? With actual schema > in 7.3, > that'll get confusing. Not renamed yet. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] findoidjoins
Joe Conway <[EMAIL PROTECTED]> writes: > Is it useful to have the reference count and unreferenced counts like > currently written, or should I just faithfully reproduce the original > behavior (except schema aware queries) using libpq in place of libpgeasy? I'd be inclined to reproduce the original behavior. findoidjoins is pretty slow already, and I don't much want to slow it down more in order to provide info that's useless for the primary purpose. > Is the oidjoins.sql test just the output of the make_oidjoins_check > script? Yes. > It is probably easier to produce that output while looping > through the first time versus running a script -- should I do that? The separation between findoidjoins and make_oidjoins_check is deliberate --- this allows for easy hand-editing of the join list to remove unwanted joins before preparing the regression test script (cf the notes in the README about bogus joins). Even though this is an extra manual step, I think it's a better answer than trying to make findoidjoins smart enough to suppress the bogus joins itself. Part of the reason for running findoidjoins is to detect any unexpected linkages, so it should not be too eager to hide things. Also, because the output of findoidjoins *should* be manually reviewed, it's better to put it out in an easy-to-read one-line-per-join format than to put out the finished regression script directly. >> I've looked through my notes and I can't find why I thought findoidjoins >> was broken for 7.3. Did you come across anything obviously wrong with >> its queries? > As written the queries did not know anything about schemas or the newer > reg* data types, e.g. this: > Does the latter produce the desired result? Not sure. My oldest note saying it was busted predates the invention of the new reg* types, I think. And while schema awareness is nice, it's not critical to the usefulness of the script: we're only really going to use it for checking the stuff in pg_catalog. So I'm not at all sure why I made that note. Do you get a plausible set of joins out of your version? 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] findoidjoins
Tom Lane wrote: > Joe Conway <[EMAIL PROTECTED]> writes: >>Is it useful to have the reference count and unreferenced counts like >>currently written, or should I just faithfully reproduce the original >>behavior (except schema aware queries) using libpq in place of libpgeasy? > > I'd be inclined to reproduce the original behavior. findoidjoins is > pretty slow already, and I don't much want to slow it down more in order > to provide info that's useless for the primary purpose. It was only taking about 7 seconds for me on an empty database, but if it's not useful I'll go back to the original output format. >>It is probably easier to produce that output while looping >>through the first time versus running a script -- should I do that? > > The separation between findoidjoins and make_oidjoins_check is > deliberate --- this allows for easy hand-editing of the join list to > remove unwanted joins before preparing the regression test script > (cf the notes in the README about bogus joins). Even though this is > an extra manual step, I think it's a better answer than trying to make > findoidjoins smart enough to suppress the bogus joins itself. Part of > the reason for running findoidjoins is to detect any unexpected > linkages, so it should not be too eager to hide things. Also, because > the output of findoidjoins *should* be manually reviewed, it's better > to put it out in an easy-to-read one-line-per-join format than to put > out the finished regression script directly. OK. I'll leave as is. >>As written the queries did not know anything about schemas or the newer >>reg* data types, e.g. this: >>Does the latter produce the desired result? > > Not sure. My oldest note saying it was busted predates the invention of > the new reg* types, I think. And while schema awareness is nice, it's > not critical to the usefulness of the script: we're only really going to > use it for checking the stuff in pg_catalog. So I'm not at all sure why > I made that note. Do you get a plausible set of joins out of your > version? Looks plausible. But I guess it will be easier to tell once it produces results in the same format as before. I'll make the changes and send it in to patches. Thanks, Joe ---(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] Bug in Makefile.shlib
- Original Message - From: "Olivier PRENANT" <[EMAIL PROTECTED]> Sent: September 04, 2002 12:18 PM > I think I figured why I can't buil plperl on unixware 711/OpenUnix 800. > > It seems Makefile.shlib has changed between 722 and 73 and -z text has > been added. However with this on, it fails to build libperl.so > > Maybe I'm wrong, but could someone consider this patch. Your patch got it backwards :) -s ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [COMMITTERS] pgsql-server/src/include/port hpux.h
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I found an HP whitepaper on the large file support and it seems they don't
> have the problem of missing declarations.
> http://docs.hp.com/hpux/onlinedocs/os/lgfiles4.pdf
> Note the example in section 6.4.1. On page 37 they grep the preprocessed
> source and somehow manage to get a declaration of __lseek64() in there.
Yeah, but you'll notice they *have to* declare __lseek64(), 'cause the
compiler will otherwise assume it returns int. I've been through these
files now and it seems that they've very carefully included only the
minimal declarations they absolutely had to. What's really annoying
is that the prototypes are there --- but #ifdef'd out of sight:
# if defined(_FILE64)
# ifndef __cplusplus
extern off_t __lseek64();
# ifdef __STDC_EXT__
static truncate(a,b) const char *a; off_t b; { return __truncate64(a,b); }
# else
static truncate(a,b) off_t b;{ return __truncate64(a,b); }
# endif /* __STDC_EXT__ */
static int prealloc(a,b) off_t b; { return __prealloc64(a,b); }
static int lockf(a,b,c) off_t c; { return __lockf64(a,b,c); }
static int ftruncate(a,b) off_t b;{ return __ftruncate64(a,b); }
static off_t lseek(a,b,c) off_t b;{ return __lseek64(a,b,c); }
# else /* __cplusplus */
extern off_t __lseek64(int, off_t, int);
extern int __truncate64(const char *, off_t);
extern int __prealloc64(int, off_t);
extern int __lockf64(int, int, off_t);
extern int __ftruncate64(int, off_t);
inline int truncate(const char *a, off_t b) { return __truncate64(a,b); }
inline int prealloc(int a, off_t b) { return __prealloc64(a,b); }
inline int lockf(int a, int b, off_t c) { return __lockf64(a,b,c); }
inline int ftruncate(int a, off_t b) { return __ftruncate64(a,b); }
inline off_t lseek(int a, off_t b, int c){ return __lseek64(a,b,c); }
# endif /* __cplusplus */
# endif /* _FILE64 */
The bottom line is that large file support does work on HPUX 10.20, but
it will generate a ton of warning messages if you build using gcc and
-Wmissing-declarations.
I'm now thinking that I will just edit my local copies of the system
headers to add the missing declarations so that I don't see these
warnings. Turning off largefile support is probably too high a price
for users to pay just so Tom Lane doesn't have to see warnings ;-)
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] findoidjoins
Patch withdrawn by author. --- Joe Conway wrote: > Tom Lane wrote: > > Alvaro Herrera <[EMAIL PROTECTED]> writes: > >>Christopher Kings-Lynne dijo: > >>>findoidjoins doens't seem to compile: > >>Seems related to the ripping of libpgeasy out of the main > >>distribution... > > > > I believe it's been broken for some time (disremember just why, maybe a > > schema issue?). I had a TODO item to resurrect it so that we could > > update the oidjoins regression test, which is sadly out of date for > > the current system catalogs. If anyone wants to work on that ... > > I'm not sure I interpreted the intent of findoidjoins just right, but > here it is updated for schemas, new reg* types, using SPI instead of > libpgeasy, and returning the results as a table function. Any > corrections/comments? If there is any interest, I'll polish this up a > bit more and submit to patches. Just let me know. > > (Should qualify as a fix, right?) > > Thanks, > > Joe > [ application/x-gzip is not supported, skipping... ] > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster -- 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/users-lounge/docs/faq.html
Re: [HACKERS] Bug in Makefile.shlib
Oops... This one should be all right!! Sorry Regards On Wed, 4 Sep 2002, Serguei Mokhov wrote: > Date: Wed, 4 Sep 2002 12:23:11 -0400 > From: Serguei Mokhov <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], pgsql-hackers list <[EMAIL PROTECTED]> > Subject: Re: [HACKERS] Bug in Makefile.shlib > > - Original Message - > From: "Olivier PRENANT" <[EMAIL PROTECTED]> > Sent: September 04, 2002 12:18 PM > > > I think I figured why I can't buil plperl on unixware 711/OpenUnix 800. > > > > It seems Makefile.shlib has changed between 722 and 73 and -z text has > > been added. However with this on, it fails to build libperl.so > > > > Maybe I'm wrong, but could someone consider this patch. > > Your patch got it backwards :) > > -s > -- 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) *** Makefile.shlib.orig mer sep 4 18:13:12 2002 --- Makefile.shlib mer sep 4 18:13:39 2002 *** *** 247,253 LINK.shared = $(CXX) -G endif endif ! LINK.shared += -Wl,-z,text -Wl,-h,$(soname) endif ifeq ($(PORTNAME), win) --- 247,253 LINK.shared = $(CXX) -G endif endif ! LINK.shared += -Wl,-h,$(soname) endif ifeq ($(PORTNAME), win) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] HISTORY updated, 7.3 branded
Tatsuo Ishii wrote: > > OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1. > > > > I used the same HISTORY categories Peter made in 7.2. I liked them. > > > > Please review the HISTORY file. I am sure there are improvements that > > can be made. > > Please change: > > > Add CREATE/DROP CONVERSION, allowing loadable encodings (Tatsuo) > > To: > > Add CREATE/DROP CONVERSION, allowing loadable encodings (Tatsuo, Kaori) > > She provided lots of encodings for CONVERSION. Done: Add CREATE/DROP CONVERSION, allowing loadable encodings (Tatsuo, Kaori) -- 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
Re: [ODBC] [HACKERS] ODBC Driver moved to GBorg ...
Hot sure if this is the right list, but. . .
On Mon, Sep 02, 2002 at 08:20:14PM -0400, Vince Vielhaber wrote:
> On Sat, 31 Aug 2002, Marc G. Fournier wrote:
>
> >
> > This is all in Vince's area ...
>
> Correction. You're not looking, it's in the users lounge. We've
> covered the button thing already.
>
> >
> >
> > On 23 Aug 2002, Greg Copeland wrote:
> >
> > > I must be blind. I don't see links to gborg anywhere on the developer
> > > or main site web pages. Perhaps more obvious a sister site link would
> > > be of value.
. . .given that so many projects are being moved out of the tree, and
given that everyone keeps talking about "gborg" on the list, would it
be possible to change the link name from "PostgreSQL Related
Projects" to "PostgreSQL Related Projects ('gborg')". Users are
going to go looking for "gborg", because that's what everyone calls
it. It'd be nice to make it real easy to find.
A
--
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<[EMAIL PROTECTED]> M2P 2A8
+1 416 646 3304 x110
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS]
I assume you have read everything on the developers web page: http://developer.postgresql.org/index.php --- ljguo_1234 wrote: > Hello, Mr. Tom Lane >I am a chinese student studied in Harbin institute of technology. I want join to >PostgreSQL Global Development Group and I want work on the planner/optimizer. I have >been reading the source code for 2 months. There many data strucutres I can't >understand. Can you tell me what document I must read first. If you have documents >about planner/optimizer of PostgreSQL, send me please. > a doctor student English name is Mohan. Chinese name is Guo long jiang. > Thank you very much! 04/09/2002 > __ > > === > ÐÂÀËÃâ·Ñµç×ÓÓÊÏä (http://mail.sina.com.cn) > ÐÂÀË·ÖÀàÐÅÏ¢£º¶þÊÖÊг¡×ßÒ»×ߣ¬¸Ã³öÊÖʱ¾Í³öÊÖ£¡ (http://classad.sina.com.cn/2shou/) > ÊýÍòÕÅÊÖ»úͼƬÊýÍòÊ׶ÌÐÅÁåÉùÈÎÄãÌôÑ¡£¬Ã¿Ì춼ÓиüР>(http://sms.sina.com.cn/cgi-bin/sms/smspic.cgi) > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > -- 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
Re: [HACKERS] HISTORY updated, 7.3 branded
Rod Taylor wrote: > Found this line without a name: > > Propagate column or table renaming to foreign key constraints > > Is that item complete? pg_constraint follows (as such dump / restore > will work) but the triggers themselves still break, don't they? No idea. The item only talks about the contraint, not the trigger. -- 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] locking of referenced table during constraint construction
Hi, Under what conditions would the following statement cause the USERS table to lock out selects? alter table my_coupons add constraint FK_mc_user_id FOREIGN KEY (mc_frn_user_id) REFERENCES users(user_ID); ss Scott Shattuck Technical Pursuit Inc. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] HISTORY updated, 7.3 branded
Alvaro Herrera wrote: > Shridhar Daithankar dijo: > > > On 4 Sep 2002 at 3:24, Bruce Momjian wrote: > > > > > OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1. > > > > Some minor stuff, > > In the schema changes description: > > "Schemas allow users to create objects in their own namespace > so two people can have the same table with the same name." > > Shouldn't it read "so two people can have tables with the same name" ? > My point is that the tables are not the same, they just have the same > name. Good point. Updated: Schemas allow users to create objects in their own namespace so two people can have tables with the same name. There is also a public schema for shared tables. Table/index creation can be restricted by removing permissions on the public schema. -- 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 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] locking of referenced table during constraint construction
On 4 Sep 2002, Scott Shattuck wrote: > Under what conditions would the following statement cause the USERS > table to lock out selects? > > > alter table my_coupons > add constraint FK_mc_user_id > FOREIGN KEY (mc_frn_user_id) > REFERENCES users(user_ID); If I'm reading code correctly, an exclusive lock on the pk table is grabbed which will block selects as well. You're effectively altering both tables (you need to add triggers to both tables) and both get locked. ---(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] HISTORY updated, 7.3 branded
OK, wording updated to add 'applications': Schemas allow users to create objects in their own namespace so two people or applications can have tables with the same name. There is also a public schema for shared tables. Table/index creation can be restricted by removing permissions on the public schema. --- [EMAIL PROTECTED] wrote: > > Shridhar Daithankar dijo: > > > > > On 4 Sep 2002 at 3:24, Bruce Momjian wrote: > > > > > > > OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1. > > > > > > Some minor stuff, > > > > In the schema changes description: > > > > "Schemas allow users to create objects in their own namespace > > so two people can have the same table with the same name." > > > Shouldn't it read "so two people can have tables with the same name" > > ? My point is that the tables are not the same, they just have the > > same name. > > How about this for a wording: > > "Schemas allow users or applications to have their own namespaces in > which to create objects. > > A typical application of this is to allow creation of tables that > _appear_ to have the same name. For instance, if some GNOME > applications were using PostgreSQL to store their configuration, a > "GNUMERIC" namespace might have a table PREFERENCES to store > preferences for that application, while a "POWERSHELL" namespace > would allow _that_ application to store configuration in a > PREFERENCES table that is quite distinct from the "GNUMERIC" one. > > The "true" table names may be GNUMERIC.PREFERENCES and > POWERSHELL.PREFERENCES, but by using Schemas, applications do not > need to be speckled with gratuitious added prefixes of GNUMERIC or > POWERSHELL." > > Note that I'm pointing at "applications" as the primary purpose for > this, as opposed to "users." > > In the long run, are not applications more likely to be the driving > force encouraging the use of schemas? > -- > (reverse (concatenate 'string "gro.gultn@" "enworbbc")) > http://www3.sympatico.ca/cbbrowne/unix.html > "The most precisely-explained and voluminously-documented user > interface "rule" can and will be shot to pieces with the introduction > of a single new priority consideration." -- Michael Peck > > > > > > ---(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 > -- 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
[HACKERS] Beta1 schedule
OK, I talked to Marc and he is going to package up beta1 tonight. Any more changes to HISTORY? I want to run pgindent in an hour. Does anyone have a problem with that? -- 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/users-lounge/docs/faq.html
Re: [HACKERS] HISTORY updated, 7.3 branded
Bruce Momjian wrote: > OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1. > > I used the same HISTORY categories Peter made in 7.2. I liked them. > > Please review the HISTORY file. I am sure there are improvements that > can be made. > A few minor comments: 1. suggested rewording: Table Functions Functions can now return sets, with multiple rows and multiple columns. You specify these functions in the SELECT FROM clause, similar to a table or view. 2. couldn't find mention of: Data Types and Functions Add named composite type creation - CREATE TYPE typename AS (column definition list) Allow anonymous composite type specification at query runtime in the table alias clause - FROM tablename AS aliasname(column definition list) Add new API to simplify creation of C language table functions Joe ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] HISTORY updated, 7.3 branded
Joe Conway wrote: > Bruce Momjian wrote: > > OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1. > > > > I used the same HISTORY categories Peter made in 7.2. I liked them. > > > > Please review the HISTORY file. I am sure there are improvements that > > can be made. > > > > A few minor comments: > > 1. suggested rewording: > > Table Functions > > Functions can now return sets, with multiple rows > and multiple columns. You specify these functions in > the SELECT FROM clause, similar to a table or view. Done. > 2. couldn't find mention of: > > Data Types and Functions > > Add named composite type creation - CREATE TYPE typename AS (column > definition list) > > Allow anonymous composite type specification at query runtime in the > table alias clause - FROM tablename AS aliasname(column definition list) > > Add new API to simplify creation of C language table functions And done: Add named composite types using CREATE TYPE typename AS (column) (Joe) Allow composite type definition in the table alias clause (Joe) Add new API to simplify creation of C language table functions (Joe) -- 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: [HACKERS] Bug in Makefile.shlib
Olivier PRENANT <[EMAIL PROTECTED]> writes: > I think I figured why I can't buil plperl on unixware 711/OpenUnix 800. > It seems Makefile.shlib has changed between 722 and 73 and -z text has > been added. Not hardly. The "-z text" option has been in there since at least 6.4. 6.4's Makefile.shlib has ifeq ($(PORTNAME), unixware) ... LDFLAGS_SL:= -G -z text ... endif which was cribbed from even older shlib support in other files. We used that up through 7.0 without any revisions. In 7.1 Makefile.shlib was revised pretty heavily; 7.1 has a unixware section that is identical to current sources, in particular LINK.shared += -Wl,-z,text -Wl,-h,$(soname) So I think this code is pretty well tested and removing the -z option is more likely to break things than fix them. What misbehavior are you seeing exactly? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Bug in Makefile.shlib
On Wed, 2002-09-04 at 12:28, Tom Lane wrote: > Olivier PRENANT <[EMAIL PROTECTED]> writes: > > I think I figured why I can't buil plperl on unixware 711/OpenUnix 800. > > > It seems Makefile.shlib has changed between 722 and 73 and -z text has > > been added. > > Not hardly. The "-z text" option has been in there since at least 6.4. > 6.4's Makefile.shlib has > > ifeq ($(PORTNAME), unixware) > ... > LDFLAGS_SL:= -G -z text > ... > endif > > which was cribbed from even older shlib support in other files. We used > that up through 7.0 without any revisions. In 7.1 Makefile.shlib was > revised pretty heavily; 7.1 has a unixware section that is identical to > current sources, in particular > > LINK.shared += -Wl,-z,text -Wl,-h,$(soname) > > So I think this code is pretty well tested and removing the -z option > is more likely to break things than fix them. > > What misbehavior are you seeing exactly? see my post from ~2 weeks ago on -hackers with a 7.2.[12] problem. It flat doesn't work. I can dig the post up if you want. > > regards, tom lane > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > -- 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] HISTORY updated, 7.3 branded
Bruce Momjian <[EMAIL PROTECTED]> writes: > Please review the HISTORY file. PostgreSQL now support ALTER TABLE ... DROP COLUMN functionality. s/support/supports/ Functions can now return sets, with multiple rows and multiple columns. You specify these functions in the SELECT FROM clause, similar to a table or view. I don't like this description: it's always been possible for functions to return sets, it was just hard to use the feature. Try to explain what we really added. Maybe: Functions returning sets (multiple rows) and/or tuples (multiple columns) are now much easier to use than before. You can call such a function in the SELECT FROM clause, treating its output like a table. Such a function can be declared to return RECORD, with the actual output column set varying from one query to the next. Also, plpgsql functions can now return sets. Both multibyte and locale are now enabled by default. s/enabled by default/always enabled/ --- AFAIK it is impossible to disable them, so "by default" is pretty misleading. By default, functions can now take up to 32 parameters, and identifiers can be up to 64 bytes long. s/64/63/ Add pg_locks table to show locks (Neil) s/table/view/ EXPLAIN now outputs as a query (Tom) This doesn't seem to belong under the Performance heading. Display sort keys in EXPLAIN (Tom) Likewise. Restrict comments to the current database Should probably say "comments on databases". Increase maximum number of function parameters to 32 (Bruce) momjian This line seems to need editing? Modify a few error messages for consistency (Bruce) momjian This too. Cleanups in array internal handling (Tom) Joe should get credit on that one. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] HISTORY updated, 7.3 branded
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Please review the HISTORY file. > >PostgreSQL now support ALTER TABLE ... DROP COLUMN functionality. > > s/support/supports/ > >Functions can now return sets, with multiple rows >and multiple columns. You specify these functions in >the SELECT FROM clause, similar to a table or view. > > I don't like this description: it's always been possible for functions > to return sets, it was just hard to use the feature. Try to explain > what we really added. Maybe: > > Functions returning sets (multiple rows) and/or tuples (multiple > columns) are now much easier to use than before. You can call > such a function in the SELECT FROM clause, treating its output > like a table. Such a function can be declared to return RECORD, > with the actual output column set varying from one query to the > next. Also, plpgsql functions can now return sets. Well, this is a summary section. That seems like too much detail. I don't remember every seeing a function returning sets before. Can you give an example? I can add the word "'easily' return sets" but I don't think it is that easy. >Both multibyte and locale are now enabled by default. > > s/enabled by default/always enabled/ --- AFAIK it is impossible to > disable them, so "by default" is pretty misleading. Done. > >By default, functions can now take up to 32 parameters, and >identifiers can be up to 64 bytes long. > > s/64/63/ Oops, got it. > Add pg_locks table to show locks (Neil) > > s/table/view/ Yep. > > EXPLAIN now outputs as a query (Tom) > > This doesn't seem to belong under the Performance heading. I had it there because EXPLAIN is a performance tool, though I wondered about that logic too. Move to utilities. > > Display sort keys in EXPLAIN (Tom) > > Likewise. Moved. > > Restrict comments to the current database > > Should probably say "comments on databases". Changed to: Restrict comment to the current database > > Increase maximum number of function parameters to 32 (Bruce) > momjian > > This line seems to need editing? Fixed. > > Modify a few error messages for consistency (Bruce) >momjian > > This too. Fixed. > > Cleanups in array internal handling (Tom) > > Joe should get credit on that one. Done. -- 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: [HACKERS] HISTORY updated, 7.3 branded
Bruce Momjian <[EMAIL PROTECTED]> writes: > I don't remember every seeing a function returning sets before. Can you > give an example? http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/xfunc-sql.html#AEN26392 Also, the preceding subsection shows SQL functions returning rows. So these features have been there, but they were messy and awkward to use. Recall that the TODO item was * -Functions returning sets do not totally work and not "we don't have functions returning sets". regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] HISTORY updated, 7.3 branded
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I don't remember every seeing a function returning sets before. Can you > > give an example? > > http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/xfunc-sql.html#AEN26392 > > Also, the preceding subsection shows SQL functions returning rows. So > these features have been there, but they were messy and awkward to use. > Recall that the TODO item was > * -Functions returning sets do not totally work > and not "we don't have functions returning sets". Yes, now I remember, only SQL functions could return sets. How about this: PL/PgSQL and C functions can now return sets, with multiple rows and multiple columns. You specify these functions in the SELECT FROM clause, similar to a table or view. -- 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/users-lounge/docs/faq.html
[HACKERS] beta1 packaged
will announce it on -announce tomorrow, if ppl want to take a quick look at it ... man pages weren't included, but I did regenerate the docs per Peter's suggested commands ... Scary, even with removing a load of stuff over to gborg, its still gotten bigger then the last release :) %ls -lt ~ftp/pub/source/v7.3beta total 21125 -rw-r--r-- 1 pgsql pgsql70 Sep 4 22:28 postgresql-test-7.3b1.tar.gz.md5 -rw-r--r-- 1 pgsql pgsql65 Sep 4 22:28 postgresql-7.3b1.tar.gz.md5 -rw-r--r-- 1 pgsql pgsql70 Sep 4 22:28 postgresql-base-7.3b1.tar.gz.md5 -rw-r--r-- 1 pgsql pgsql70 Sep 4 22:28 postgresql-docs-7.3b1.tar.gz.md5 -rw-r--r-- 1 pgsql pgsql69 Sep 4 22:28 postgresql-opt-7.3b1.tar.gz.md5 -rw-r--r-- 1 pgsql pgsql 1070154 Sep 4 22:28 postgresql-test-7.3b1.tar.gz -rw-r--r-- 1 pgsql pgsql 2629533 Sep 4 22:28 postgresql-opt-7.3b1.tar.gz -rw-r--r-- 1 pgsql pgsql 2577818 Sep 4 22:28 postgresql-docs-7.3b1.tar.gz -rw-r--r-- 1 pgsql pgsql 4505929 Sep 4 22:28 postgresql-base-7.3b1.tar.gz -rw-r--r-- 1 pgsql pgsql 10783992 Sep 4 22:27 postgresql-7.3b1.tar.gz ---(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] HISTORY updated, 7.3 branded
Bruce Momjian <[EMAIL PROTECTED]> writes: > Yes, now I remember, only SQL functions could return sets. How about > this: >PL/PgSQL and C functions can now return sets, with multiple >rows and multiple columns. You specify these functions in the >SELECT FROM clause, similar to a table or view. C functions have always been able to return sets too; you don't honestly think that a SQL function can do something a C function can't, do you? There are really two independent improvements here: one is the ability for plpgsql functions to return sets, and the other is a group of improvements that make it easier to use a function-returning-set, independently of what language it's written in. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] HISTORY updated, 7.3 branded
Tom Lane wrote: > C functions have always been able to return sets too; you don't honestly > think that a SQL function can do something a C function can't, do you? The original dblink is an example. > > There are really two independent improvements here: one is the ability > for plpgsql functions to return sets, and the other is a group of > improvements that make it easier to use a function-returning-set, > independently of what language it's written in. > As an example, although you *could* return a composite type before, it was almost useless, because what you actually got returned to you was a pointer: test=# create function get_foo() returns setof foo as 'select * from foo' language sql; CREATE test=# select get_foo(); get_foo --- 137867648 137867648 137867648 (3 rows) In order to get the individual columns, you had to do: test=# select f1(get_foo()), f2(get_foo()), f3(get_foo()); f1 | f2 | f3 ++- 1 | 1 | abc 1 | 2 | def 2 | 1 | ghi (3 rows) Pretty ugly, but it did work. What about this: Functions returning multiple rows and/or multiple columns are now much easier to use than before. You can call such a "table function" in the SELECT FROM clause, treating its output like a table. Also, plpgsql functions can now return sets. Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] HISTORY updated, 7.3 branded
Joe Conway wrote: > What about this: > > Functions returning multiple rows and/or multiple columns are > now much easier to use than before. You can call such a > "table function" in the SELECT FROM clause, treating its output > like a table. Also, plpgsql functions can now return sets. Added. -- 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
Re: [HACKERS] Bug in Makefile.shlib
Well, Tom and Larry, I've posted already on -hackers but my posts did'nt semm to get through! The problem is that at link time, ld complains about text segment beeing written to in Dynaloader. The only way was to remove -Wl,-z text. I agree this sounded stupid. But I can't think of something else. This is with perl-5.6.1 FWIW Regards On 4 Sep 2002, Larry Rosenman wrote: > Date: 04 Sep 2002 12:37:35 -0500 > From: Larry Rosenman <[EMAIL PROTECTED]> > To: Tom Lane <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], pgsql-hackers list <[EMAIL PROTECTED]> > Subject: Re: [HACKERS] Bug in Makefile.shlib > > On Wed, 2002-09-04 at 12:28, Tom Lane wrote: > > Olivier PRENANT <[EMAIL PROTECTED]> writes: > > > I think I figured why I can't buil plperl on unixware 711/OpenUnix 800. > > > > > It seems Makefile.shlib has changed between 722 and 73 and -z text has > > > been added. > > > > Not hardly. The "-z text" option has been in there since at least 6.4. > > 6.4's Makefile.shlib has > > > > ifeq ($(PORTNAME), unixware) > > ... > > LDFLAGS_SL:= -G -z text > > ... > > endif > > > > which was cribbed from even older shlib support in other files. We used > > that up through 7.0 without any revisions. In 7.1 Makefile.shlib was > > revised pretty heavily; 7.1 has a unixware section that is identical to > > current sources, in particular > > > > LINK.shared += -Wl,-z,text -Wl,-h,$(soname) > > > > So I think this code is pretty well tested and removing the -z option > > is more likely to break things than fix them. > > > > What misbehavior are you seeing exactly? > see my post from ~2 weeks ago on -hackers with a 7.2.[12] problem. > > It flat doesn't work. > > I can dig the post up if you want. > > > > > > regards, tom lane > > > > ---(end of broadcast)--- > > TIP 5: Have you checked our extensive FAQ? > > > > http://www.postgresql.org/users-lounge/docs/faq.html > > > -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Bug in Makefile.shlib
Me again!! These are errors I get with orginal Makefile.shlib: Warning: No bytecode->native mapping for a bytecode Warning: JIT compiler failed for org/apache/crimson/parser/Parser2.maybeComment(Z)Z UX:ld: INFO: text relocations referenced from files: DynaLoader.a(DynaLoader.o) UX:ld: ERROR: relocations remain against non-writeable, allocatable section .text gmake[3]: *** [libplperl.so.0.0] Error 1 gmake[2]: *** [all] Error 2 gmake[1]: *** [all] Error 2 gmake: *** [all] Error 2 UX:make: ERROR: fatal error. Regards, On 4 Sep 2002, Larry Rosenman wrote: > Date: 04 Sep 2002 12:37:35 -0500 > From: Larry Rosenman <[EMAIL PROTECTED]> > To: Tom Lane <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], pgsql-hackers list <[EMAIL PROTECTED]> > Subject: Re: [HACKERS] Bug in Makefile.shlib > > On Wed, 2002-09-04 at 12:28, Tom Lane wrote: > > Olivier PRENANT <[EMAIL PROTECTED]> writes: > > > I think I figured why I can't buil plperl on unixware 711/OpenUnix 800. > > > > > It seems Makefile.shlib has changed between 722 and 73 and -z text has > > > been added. > > > > Not hardly. The "-z text" option has been in there since at least 6.4. > > 6.4's Makefile.shlib has > > > > ifeq ($(PORTNAME), unixware) > > ... > > LDFLAGS_SL:= -G -z text > > ... > > endif > > > > which was cribbed from even older shlib support in other files. We used > > that up through 7.0 without any revisions. In 7.1 Makefile.shlib was > > revised pretty heavily; 7.1 has a unixware section that is identical to > > current sources, in particular > > > > LINK.shared += -Wl,-z,text -Wl,-h,$(soname) > > > > So I think this code is pretty well tested and removing the -z option > > is more likely to break things than fix them. > > > > What misbehavior are you seeing exactly? > see my post from ~2 weeks ago on -hackers with a 7.2.[12] problem. > > It flat doesn't work. > > I can dig the post up if you want. > > > > > > regards, tom lane > > > > ---(end of broadcast)--- > > TIP 5: Have you checked our extensive FAQ? > > > > http://www.postgresql.org/users-lounge/docs/faq.html > > > -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Bug in Makefile.shlib
Olivier PRENANT <[EMAIL PROTECTED]> writes: > The problem is that at link time, ld complains about text segment beeing > written to in Dynaloader. > I agree this sounded stupid. But I can't think of something else. > This is with perl-5.6.1 FWIW Ah. This is a bug in Perl's build process: even if you request a shared library, it builds DynaLoader as static code. My own notes about installing perl 5.6.1 on HPUX read: make fix DynaLoader.o per below make test make install At least in 5.6.1, even with "build shared" request, DynaLoader.o is not made with +z, which will cause plperl to fail. To fix, simply go into perl-5.6.1/ext/DynaLoader, rm DynaLoader.o, and "make". I wonder why toplevel makefile thinks it's okay to build DynaLoader static?? I'm just now in the middle of installing Perl 5.8.0, and it seems that the oversight has been fixed; DynaLoader is now built sharable: cc -c -Ae -D_HPUX_SOURCE -Wl,+vnocompatwarnings -DDEBUGGING -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -DVERSION=\"1.04\" -DXS_VERSION=\"1.04\" +Z "-I../.." -DPERL_CORE -DLIBC="/lib/libc.sl" DynaLoader.c There seem to be some other problems --- 7.2 plperl dumps core for me even with the above fix. Still looking into that (I'm sorta hoping that 5.8.0 will fix it, but won't know for a little while...) regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Bug in Makefile.shlib
Hi Tom, Thanks fr your reply.. Not sure I understood! I've tried your hack with no luck. Further more, README in perl/ext/Dynaloader says it has to be static to be effective. What concerns me more is that with same perl (5.6.1) it compiles ok with 722. Regards On Wed, 4 Sep 2002, Tom Lane wrote: > Date: Wed, 04 Sep 2002 17:14:13 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: Larry Rosenman <[EMAIL PROTECTED]>, > pgsql-hackers list <[EMAIL PROTECTED]> > Subject: Re: [HACKERS] Bug in Makefile.shlib > > Olivier PRENANT <[EMAIL PROTECTED]> writes: > > The problem is that at link time, ld complains about text segment beeing > > written to in Dynaloader. > > I agree this sounded stupid. But I can't think of something else. > > This is with perl-5.6.1 FWIW > > Ah. This is a bug in Perl's build process: even if you request a shared > library, it builds DynaLoader as static code. My own notes about > installing perl 5.6.1 on HPUX read: > > make > fix DynaLoader.o per below > make test > make install > > At least in 5.6.1, even with "build shared" request, DynaLoader.o is not > made with +z, which will cause plperl to fail. To fix, simply go into > perl-5.6.1/ext/DynaLoader, rm DynaLoader.o, and "make". I wonder why > toplevel makefile thinks it's okay to build DynaLoader static?? > > > I'm just now in the middle of installing Perl 5.8.0, and it seems that > the oversight has been fixed; DynaLoader is now built sharable: > > cc -c -Ae -D_HPUX_SOURCE -Wl,+vnocompatwarnings -DDEBUGGING -I/usr/local/include >-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -DVERSION=\"1.04\" >-DXS_VERSION=\"1.04\" +Z "-I../.." -DPERL_CORE -DLIBC="/lib/libc.sl" DynaLoader.c > > There seem to be some other problems --- 7.2 plperl dumps core for me > even with the above fix. Still looking into that (I'm sorta hoping that > 5.8.0 will fix it, but won't know for a little while...) > > regards, tom lane > -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Future of --enable-recode?
Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > Now that the "multibyte"-based character set recoding is a fixed part of > > the feature set, is there any need to keep the "Cyrillic" recode support? > > It's probably not worth maintaining anymore ... Added to TODO: > * Remove Cyrillic recode support -- 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 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] Bug in Makefile.shlib
Olivier PRENANT <[EMAIL PROTECTED]> writes: > Thanks fr your reply.. Not sure I understood! > I've tried your hack with no luck. Further more, README in > perl/ext/Dynaloader says it has to be static to be effective. That's talking about whether it's linked into perl, not whether it's compiled PIC or not. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Beta1 schedule
Bruce Momjian <[EMAIL PROTECTED]> writes: > Any more changes to HISTORY? This is missing: - Implemented START TRANSACTION, per SQL99 (Neil) This was implemented by Peter, I think: - Add privileges on functions and procedural languages This was done by Tom, IIRC: - Triggers are now fired in alphabetical order This could probably be better phrased: - Have PL/PgSQL FOUND return proper value for PERFORM and SELECT INTO (Tom, Neil) As (reword as necessary): - Overhaul the PL/PgSQL FOUND magic variable to be more Oracle-compatible, and generally more sane. (Tom, Neil) This was implemented by me and Jukka Holappa: - Clean up use of sprintf in favor of snprintf() Tom did some work on this as well as Chris, I believe: - Add ALTER TABLE DROP COLUMN (Christopher) I didn't see any mention of Tom's recent changes to the on-disk array storage format, but I might have just missed that. Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Multibyte support in oracle_compat.c
Tatsuo Ishii writes: > > Functions upper,lower and initcap doesn't work with utf-8 data The backend routines use the host OS locales, so look there. On my machine I have several Russian locales, which seem to address the issue of character sets: ru_RU ru_RU.koi8r ru_RU.utf8 ru_UA russian This is bogus, because the LC_CTYPE choice is cluster-wide and the encoding choice is database-specific (in other words: it's broken), but there's nothing we can do about that right now. > > P.S.It doesn't seem bad for me to use lib unicode instead of functions like >mbtowc,wctomb from stdlib and towupper,towlower from wctype > > I'm not sure. What do you think, Peter or other guys who is familiar > with Unicode? I don't know that that libunicode is, but that shouldn't prevent us from possibly evaluating it. :-) Btw., I just happened to think about this very issue over the last few days. What I would like to attack for the next release is to implement character classification and conversion using the Unicode tables so we can cut the LC_CTYPE system locale out of the picture. Perhaps this is what the poster was thinking of, too. -- 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])
[HACKERS] contrib Makefile
I just tried to build all of contrib, and it stops at earthdistance. Looks like this is the cause: [...] dbmirror\ dbsize \ earthdistance \ # findoidjoins\ fulltextindex \ [...] The comment on findoidjoins breaks the line continuation, doesn't it? Joe ---(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] more contrib breakage
I'm also getting a failure on tsearch: make[1]: Entering directory `/opt/src/pgsql/contrib/tsearch' gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I. -I../../src/include -c -o morph.o morph.c -MMD morph.c: In function `initmorph': morph.c:107: `PG_LocaleCategories' undeclared (first use in this function) morph.c:107: (Each undeclared identifier is reported only once morph.c:107: for each function it appears in.) morph.c:107: parse error before `lc' morph.c:116: warning: implicit declaration of function `PGLC_current' morph.c:116: `lc' undeclared (first use in this function) morph.c:124: warning: implicit declaration of function `PGLC_free_categories' make[1]: *** [morph.o] Error 1 make[1]: Leaving directory `/opt/src/pgsql/contrib/tsearch' Joe ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Open pg_dump issues
Here are a few open concerns about pg_dump: Critical: * pg_dumpall is not compatible with pre-7.3. It used to be ignorant but now that it has extra columns in pg_database and pg_user to take care of it will break with older releases. This should be straightforward to fix for me (I hope) within the next few days. * pg_dumpall doesn't know about the new database-level privileges, yet. Non-critical: * The pg_dumpall documentation contains this: | -c, --clean | | Include SQL commands to clean (drop) database objects before | recreating them. (This option is fairly useless, since the output script | expects to create the databases themselves; they would always be empty | upon creation.) pg_dumpall processes this option itself and puts out DROP DATABASE commands for each database dumped, which seems to be a reasonable feature. Perhaps the option should not be passed through to pg_dump (where it is useless) and the documentation should be changed to reflect that. * The --ignore-version description says that pg_dump only works with servers of the same release. Nowadays we take great care to make it backward compatible, so the documentation should be changed if we want to publicize that. * The "disable trigger" feature currently puts out code like this: -- Disable triggers UPDATE pg_catalog.pg_class SET reltriggers = 0 WHERE oid = 'char_tbl'::pg_catalog.regclass; COPY char_tbl (f1) FROM stdin; a ab abcd abcd \. -- Enable triggers UPDATE pg_catalog.pg_class SET reltriggers = (SELECT pg_catalog.count(*) FROM pg_catalog.pg_trigger where pg_class.oid = tgrelid) WHERE oid = 'char_tbl'::pg_catalog.regclass; As the pg_dump man page correctly advises, this may leave the system catalogs corrupted if the restore is interrupted. I was wondering why we don't do this: BEGIN; UPDATE ... COPY ... UPDATE ... COMMIT; -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PL/Perl?
Larry Rosenman <[EMAIL PROTECTED]> writes: > I upgraded PostgreSQL to 7.2.1 from a 7.2beta (yeah, I know). One of my > users requested plperl, so I got it to createlang, but it SIGSEGV's on > any simple perl. I was seeing the same with perl 5.6.1 and PG 7.2.* on HPUX 10.20. However, I have just verified that perl 5.8.0 works okay with PG CVS tip (not much testing, but it handles a simple plperl function). Could you see whether 5.8.0 plays any nicer on your setup? 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] Multibyte support in oracle_compat.c
On Thu, 5 Sep 2002, Peter Eisentraut wrote: > Date: Thu, 5 Sep 2002 00:46:39 +0200 (CEST) > From: Peter Eisentraut <[EMAIL PROTECTED]> > To: Tatsuo Ishii <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: Re: [HACKERS] Multibyte support in oracle_compat.c > > Tatsuo Ishii writes: > > > > Functions upper,lower and initcap doesn't work with utf-8 data > > The backend routines use the host OS locales, so look there. On my > machine I have several Russian locales, which seem to address the issue of > character sets: > > ru_RU > ru_RU.koi8r > ru_RU.utf8 > ru_UA > russian Yeah, our character sets is a major pain for internatianlization. And the above list is not exhaustive. I guess you are right, for the time being you'll have to bear with it. -s ---(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] Beta1 schedule
Hannu Krosing wrote: > On Thu, 2002-09-05 at 03:17, Neil Conway wrote: > > > > Tom did some work on this as well as Chris, I believe: > > > > - Add ALTER TABLE DROP COLUMN (Christopher) > > IIRC, some of it was originally based on Hiroshi's earlyer trial code, > so he should probably be mentioned as well ? Yes, absolutely: Add ALTER TABLE DROP COLUMN (Christopher, Hiroshi) -- 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/users-lounge/docs/faq.html
Re: [HACKERS] Beta1 schedule
Neil Conway wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Any more changes to HISTORY? > > This is missing: > > - Implemented START TRANSACTION, per SQL99 (Neil) Done. I didn't mention it earlier because I was unsure of its significance. > This was implemented by Peter, I think: > > - Add privileges on functions and procedural languages Yep, fixed. > > This was done by Tom, IIRC: > > - Triggers are now fired in alphabetical order Yep, Tom. > > This could probably be better phrased: > > - Have PL/PgSQL FOUND return proper value for PERFORM and SELECT INTO > (Tom, Neil) Done. > > As (reword as necessary): > > - Overhaul the PL/PgSQL FOUND magic variable to be more > Oracle-compatible, and generally more sane. (Tom, Neil) > > This was implemented by me and Jukka Holappa: > > - Clean up use of sprintf in favor of snprintf() Added. > > Tom did some work on this as well as Chris, I believe: > > - Add ALTER TABLE DROP COLUMN (Christopher) > Added. > I didn't see any mention of Tom's recent changes to the on-disk array > storage format, but I might have just missed that. I already see it. I added Tom's name too: Cleanups in array internal handling (Joe, Tom) -- 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 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] locking of referenced table during constraint
On Wed, 2002-09-04 at 15:51, Stephan Szabo wrote: > > On 4 Sep 2002, Scott Shattuck wrote: > > > Under what conditions would the following statement cause the USERS > > table to lock out selects? > > > > > > alter table my_coupons > > add constraint FK_mc_user_id > > FOREIGN KEY (mc_frn_user_id) > > REFERENCES users(user_ID); > > If I'm reading code correctly, an exclusive lock > on the pk table is grabbed which will block selects > as well. You're effectively altering both tables > (you need to add triggers to both tables) and > both get locked. > > Ok, if I understand things correctly the USERS table gets a constraint that says don't delete/update the USER_ID in any way that would orphan a row in the MY_COUPONS table. The MY_COUPONS table gets one that says don't insert/update MC_FRN_USER_ID such that it isn't found in USERS.USER_ID. But... There are no rows in the my_coupons table so it's not possible to orphan a row there -- were it even the case that an update or delete were running...which they aren't. Even if there were rows in the referring table I don't understand why an exclusive table-level lock is being taken out to add a trigger. If I add user-level triggers to do the same task they go in without a hitch but cause other problems in 7.2 since I can't control their order of execution yet (thanks Tom for the 7.3 patch! :)). ss > > ---(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])
Re: [HACKERS] locking of referenced table during constraint
Scott Shattuck <[EMAIL PROTECTED]> writes: > ... I don't understand why an exclusive table-level lock is being > taken out to add a trigger. Well, that's a schema change; it makes sense to me to forbid access while we're changing a table's schema. I think this discussion may just be a miscommunication: it's not clear to me whether you're complaining about adding a trigger or just firing a trigger. The former is not a time-critical task in my book ... 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])
[HACKERS] Largefile fallout: postgres.h MUST be included first
A long time ago you mentioned in passing that postgres.h should be included before including any system headers. I have been desultorily changing files to meet that rule, but AFAIK no one's made a pass to ensure that it's followed everywhere. Well, now we have a reason it had better be that way: largefile support will break otherwise. Since we've arranged to define stuff like _FILE_OFFSET_BITS in pg_config.h which is included by postgres.h, it is *critical* to read postgres.h before reading any system headers. Otherwise you are likely to see non-64-bit-aware definitions of library routines, FILE structs, etc. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PL/Perl?
On Wed, 2002-09-04 at 17:54, Tom Lane wrote: > Larry Rosenman <[EMAIL PROTECTED]> writes: > > I upgraded PostgreSQL to 7.2.1 from a 7.2beta (yeah, I know). One of my > > users requested plperl, so I got it to createlang, but it SIGSEGV's on > > any simple perl. > > I was seeing the same with perl 5.6.1 and PG 7.2.* on HPUX 10.20. > However, I have just verified that perl 5.8.0 works okay with PG CVS tip > (not much testing, but it handles a simple plperl function). Could you > see whether 5.8.0 plays any nicer on your setup? Need to check with my user, I'll let ya know. LER > > regards, tom lane -- 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] Open pg_dump issues
Peter Eisentraut <[EMAIL PROTECTED]> writes: > I was wondering why we > don't do this: > BEGIN; > UPDATE ... > COPY ... > UPDATE ... > COMMIT; Seems like a good idea. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Multibyte support in oracle_compat.c
> The backend routines use the host OS locales, so look there. On my > machine I have several Russian locales, which seem to address the issue of > character sets: > > ru_RU > ru_RU.koi8r > ru_RU.utf8 > ru_UA > russian > > This is bogus, because the LC_CTYPE choice is cluster-wide and the > encoding choice is database-specific (in other words: it's broken), but > there's nothing we can do about that right now. I thought his idea was using UTF-8 locale and Unicode (UTF-8) encoded database. > Btw., I just happened to think about this very issue over the last few > days. What I would like to attack for the next release is to implement > character classification and conversion using the Unicode tables so we can > cut the LC_CTYPE system locale out of the picture. Perhaps this is what > the poster was thinking of, too. Interesting idea. If you are saying that you are going to remove the dependecy on system locale, I will agree with your idea. BTW, nls has same problem as above, no? I guess nls depeneds on locale and it may conflict with the database-specific encoding and/or the automatic FE/BE encoding conversion. -- Tatsuo Ishii ---(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] Inheritance
On Tue, 3 Sep 2002, Bruce Momjian wrote: > Yep, this is where we are stuck; having an index span multiple tables > in some way. Or implementing it by keeping all data in the table in which it was declared. (I.e., supertable holds all rows; subtable holds only the primary key and those columns of the row that are not in the supertable.) >From looking at the various discussions of this in books, and what it appears to me that the SQL standard says, it seems that their overall vision of table inheritance is to be consistent with the implementation that I described above. cjs -- Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(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.2 - 7.3 activity
Can someone maybe do a bit of a 'wc' on the cvs logs to see how much we've changed between 7.2 - 7.3 compared to 7.1 - 7.2? It's evident that the HISTORY file shows many more changes in this release than the previous, and I think it'd be interesting to know how much/how fast postgres is gaining momentum, what the developer appearance and attrition rate is, etc. Just interesting... Chris ---(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] Beta1 schedule
> Hannu Krosing wrote: > > On Thu, 2002-09-05 at 03:17, Neil Conway wrote: > > > > > > Tom did some work on this as well as Chris, I believe: > > > > > > - Add ALTER TABLE DROP COLUMN (Christopher) > > > > IIRC, some of it was originally based on Hiroshi's earlyer trial code, > > so he should probably be mentioned as well ? > > Yes, absolutely: > > Add ALTER TABLE DROP COLUMN (Christopher, Hiroshi) While we're competing for the humble award, you might want to add Tom to that list... Chris ---(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] Beta1 schedule
It would be far simpler to put each of the core teams names on the top of the history file in big bold letters -- or perhaps a watermark in the background ;) > While we're competing for the humble award, you might want to add Tom to > that list... ---(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] more contrib breakage
Oleg knows about it and is planning to fix it. Chris > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Joe Conway > Sent: Thursday, 5 September 2002 11:55 AM > To: pgsql-hackers > Subject: [HACKERS] more contrib breakage > > > I'm also getting a failure on tsearch: > > make[1]: Entering directory `/opt/src/pgsql/contrib/tsearch' > gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I. > -I../../src/include -c -o morph.o morph.c -MMD > morph.c: In function `initmorph': > morph.c:107: `PG_LocaleCategories' undeclared (first use in this function) > morph.c:107: (Each undeclared identifier is reported only once > morph.c:107: for each function it appears in.) > morph.c:107: parse error before `lc' > morph.c:116: warning: implicit declaration of function `PGLC_current' > morph.c:116: `lc' undeclared (first use in this function) > morph.c:124: warning: implicit declaration of function > `PGLC_free_categories' > make[1]: *** [morph.o] Error 1 > make[1]: Leaving directory `/opt/src/pgsql/contrib/tsearch' > > > Joe > > > ---(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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Beta1 schedule
Christopher Kings-Lynne wrote: > > Hannu Krosing wrote: > > > On Thu, 2002-09-05 at 03:17, Neil Conway wrote: > > > > > > > > Tom did some work on this as well as Chris, I believe: > > > > > > > > - Add ALTER TABLE DROP COLUMN (Christopher) > > > > > > IIRC, some of it was originally based on Hiroshi's earlyer trial code, > > > so he should probably be mentioned as well ? > > > > Yes, absolutely: > > > > Add ALTER TABLE DROP COLUMN (Christopher, Hiroshi) > > While we're competing for the humble award, you might want to add Tom to > that list... Already done, with Hiroshi too: Add ALTER TABLE DROP COLUMN (Christopher, Tom, Hiroshi) -- 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 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] TODO item on triggers
Is this item completed? It sure looks like it: * Make triggers refer to columns by number, not name test=> \d pg_trigger Table "pg_catalog.pg_trigger" Column |Type| Modifiers ++--- tgrelid| oid| not null tgname | name | not null tgfoid | oid| not null tgtype | smallint | not null tgenabled | boolean| not null tgisconstraint | boolean| not null tgconstrname | name | not null tgconstrrelid | oid| not null tgdeferrable | boolean| not null tginitdeferred | boolean| not null tgnargs| smallint | not null tgattr | int2vector | not null tgargs | bytea | -- 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 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] locking of referenced table during constraint
On 4 Sep 2002, Scott Shattuck wrote: > On Wed, 2002-09-04 at 15:51, Stephan Szabo wrote: > > > > On 4 Sep 2002, Scott Shattuck wrote: > > > > > Under what conditions would the following statement cause the USERS > > > table to lock out selects? > > > > > > > > > alter table my_coupons > > > add constraint FK_mc_user_id > > > FOREIGN KEY (mc_frn_user_id) > > > REFERENCES users(user_ID); > > > > If I'm reading code correctly, an exclusive lock > > on the pk table is grabbed which will block selects > > as well. You're effectively altering both tables > > (you need to add triggers to both tables) and > > both get locked. > > > > > > Ok, if I understand things correctly the USERS table gets a constraint > that says don't delete/update the USER_ID in any way that would orphan a > row in the MY_COUPONS table. The MY_COUPONS table gets one that says > don't insert/update MC_FRN_USER_ID such that it isn't found in > USERS.USER_ID. > > But... > > There are no rows in the my_coupons table so it's not possible to orphan > a row there -- were it even the case that an update or delete were > running...which they aren't. Even if there were rows in the referring > table I don't understand why an exclusive table-level lock is being > taken out to add a trigger. If I add user-level triggers to do the same > task they go in without a hitch but cause other problems in 7.2 since I > can't control their order of execution yet (thanks Tom for the 7.3 > patch! :)). I see the same behavior with user triggers (on my 7.3 devel box) if you don't commit the transaction that selects against the table that is having the trigger added to it block until the transaction that did the create trigger is committed or aborted. I think I must be misunderstanding the symptoms. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] locking of referenced table during constraint
On Wed, 2002-09-04 at 22:49, Tom Lane wrote: > Scott Shattuck <[EMAIL PROTECTED]> writes: > > ... I don't understand why an exclusive table-level lock is being > > taken out to add a trigger. > > Well, that's a schema change; it makes sense to me to forbid access > while we're changing a table's schema. > No. In my book a schema change would alter the data a query would see -- as in drop column, or add column, etc. This is simply a "don't let a delete/update get past this trigger from this point forward". That's not a bar-the-gates kind of scenario to me. More like "for any DML operating after the current version stamp make sure this trigger runs." Why lock anything? One scenario I can see. A delete starting at T0 doesn't see a trigger. The alter occurs at T1 but, due to ACID, the delete doesn't see it. The delete tries to commit at T2. Unfortunately, in that scenario you can envision an issue since it would seem the delete should fail since the alter is done, but the delete's transaction shouldn't be able to be affected by things starting after it does. So, a conflict. But only for a delete or update. Selects already have transaction isolation levels...why don't they allow the selects to read through adding a constraint? I have other serious issues with locking and FK constraints as it is. They often cause us serious performance problems. Sadly, the longer I use PG and get hammered by locking issues surrounding the FK constraint implementation the less I find myself likely to suggest PG for similar customers in the future. > I think this discussion may just be a miscommunication: it's not clear > to me whether you're complaining about adding a trigger or just firing > a trigger. The former is not a time-critical task in my book ... > It becomes time critical when the table has 3 million user account entries and the lock blocks people from having their login name verified, causing what's supposed to be a 24x7 e-commerce site to essentially go offline to users for 5 minutes or more just so you can add a constraint to a new table with no rows. Sorry, but that sucks. ss ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [COMMITTERS] pgsql-server/doc TODO
Hang on - try looking at the tgargs field. I bet it still refers to fields by their name, not their number... Chris > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Bruce Momjian > - CVS > Sent: Thursday, 5 September 2002 12:58 PM > To: [EMAIL PROTECTED] > Subject: [COMMITTERS] pgsql-server/doc TODO > > > CVSROOT: /cvsroot > Module name: pgsql-server > Changes by: [EMAIL PROTECTED] 02/09/05 00:58:28 > > Modified files: > doc: TODO > > Log message: > Done: > > > * -Make triggers refer to columns by number, not name > > > ---(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 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] Map of developers
Anyone else think we should add some more pins to the developer map? At the moment, it looks like we have very few developers! Chris ---(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] [COMMITTERS] pgsql-server/doc TODO
Yep, I see in regression database: tgargs --- clstr_tst_con\000clstr_tst\000clstr_tst_s\000UNSPECIFIED\000b\000rf_a\000 clstr_tst_con\000clstr_tst\000clstr_tst_s\000UNSPECIFIED\000b\000rf_a\000 clstr_tst_con\000clstr_tst\000clstr_tst_s\000UNSPECIFIED\000b\000rf_a\000 clstr_tst_con\000clstr_tst\000clstr_tst_s\000UNSPECIFIED\000b\000rf_a\000 TODO updated to: * Make pg_trigger.tgargs refer to columns by number, not name --- Christopher Kings-Lynne wrote: > Hang on - try looking at the tgargs field. I bet it still refers to fields > by their name, not their number... > > Chris > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Bruce Momjian > > - CVS > > Sent: Thursday, 5 September 2002 12:58 PM > > To: [EMAIL PROTECTED] > > Subject: [COMMITTERS] pgsql-server/doc TODO > > > > > > CVSROOT:/cvsroot > > Module name:pgsql-server > > Changes by: [EMAIL PROTECTED] 02/09/05 00:58:28 > > > > Modified files: > > doc: TODO > > > > Log message: > > Done: > > > > > * -Make triggers refer to columns by number, not name > > > > > > ---(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 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 > -- 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 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] Map of developers
I will work on that this month. It is part of the advocacy project. --- Christopher Kings-Lynne wrote: > Anyone else think we should add some more pins to the developer map? At the > moment, it looks like we have very few developers! > > Chris > > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > -- 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: [HACKERS] 7.2 - 7.3 activity
Christopher Kings-Lynne wrote: > Can someone maybe do a bit of a 'wc' on the cvs logs to see how much we've > changed between 7.2 - 7.3 compared to 7.1 - 7.2? It's evident that the > HISTORY file shows many more changes in this release than the previous, and > I think it'd be interesting to know how much/how fast postgres is gaining > momentum, what the developer appearance and attrition rate is, etc. Good question. As far as lines of *.[chy] code in pgsql/src, you have: Date | Release | Lines of code --+--+ 1994| | 244,581 1996-08-01 | 1.02.1 | 1996-10-27 |1.09 | 178,976 1997-01-29 | 6.0 | 1997-06-08 | 6.1 | 200,709 1997-10-02 | 6.2 | 225,848 1998-03-01 | 6.3 | 260,809 1998-10-30 | 6.4 | 297,918 1999-06-09 | 6.5 | 331,278 2000-05-08 | 7.0 | 383,270 2001-04-13 | 7.1 | 410,500 2002-02-04 | 7.2 | 394,274 2002-??-?? | 7.3 | 453,282 As you can see, a 15% increase over 7.2. As far as the feature list, 7.3 has the largest list ever, again about a 15% increase. -- 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/users-lounge/docs/faq.html
Re: [HACKERS] Beta1 schedule
Line 72 of the HISTORY file (the one in 7.3b1 that Marc just packaged) reads: * Pre-6.3 clients are no longer supported. Is that supposed to be 7.3? I assume you're referring to the catalog changes, &c. that make old clients that are dependent on them behave incorrectly. Regards, Jeff Davis On Wednesday 04 September 2002 10:09 am, Bruce Momjian wrote: > OK, I talked to Marc and he is going to package up beta1 tonight. > > Any more changes to HISTORY? > > I want to run pgindent in an hour. Does anyone have a problem with > that? ---(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] Beta1 schedule
> * Pre-6.3 clients are no longer supported. > > Is that supposed to be 7.3? I assume you're referring to the > catalog changes, > &c. that make old clients that are dependent on them behave incorrectly. > > Regards, > Jeff Davis No, he's referring to the on-the-wire protocol. This means that the psql program that came with 6.2 will not work with 7.3, but the 7.2 psql will still (mostly) work. Chris ---(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] I am done
On Wed, 4 Sep 2002, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > Does anyone else have an opinion on this? If not, I will implement it per
> > Bruce's commentary.
>
> > On Mon, 2 Sep 2002, Bruce Momjian wrote:
> >> I think the second, passing an arg to say whether it is server or
> >> client, will do the trick, though now you need an error one too. I
> >> guess you have to use #define and set it, or pass a string down with the
> >> GUC variable and test that with strcmp.
>
> I think you're going to end up un-merging the routines. There is no way
> to pass an extra parameter to the set/check routines (at least not
There is a wrapper around the generic function:
const char *
assign_min_error_statement(const char *newval, bool doit, bool
interactive)
{
return(assign_msglvl(&log_min_error_statement,newval,doit,interactive));
}
I would simply define some macros:
#define MSGLVL_MIN_ERR_STMT (1<<0)
#define MSGLVL_MIN_CLI_MSGS (1<<1)
#define MSGLVL_MIN_SVR_MSGS (1<<2)
And assign_msglvl(), having been passed the variable 'caller', determined
by the calling function, will do something like this:
/* everyone has likes debug */
if (strcasecmp(newval, "debug") == 0 &&
caller & (MSGLVL_MIN_ERR_STMT | MSGLVL_MIN_CLI_MSGS | MSGLVL_MIN_SVR_MSGS))
{ if (doit) (*var) = DEBUG1; }
/* ... */
else if (strcasecmp(newval, "fatal") == 0 &&
caller & (MSGLVL_MIN_ERR_STMT | MSGLVL_MIN_SVR_MSGS))
{ if (doit) (*var) = FATAL; }
else if (strcasecmp(newval, "off") == 0 &&
caller & MSGLVL_MIN_ERR_STMT)
{ if (doit) (*var) = MIN_ERR_STMT_OFF; }
Personally, I've never liked coding like this. The reason I merged the
base code for each function was so that the GUC code didn't get uglier as
more minimum-level-of-logging parameters were added. But with the code
above, the bitwise operations and appearance of the
assign_msglvl() routine will suffer the same fate, I'm afraid.
Since the flawed code is now in beta, it will need to be fixed. Do people
like the above solution or should I just revert to having a seperate
function for each GUC variable affected?
Gavin
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Please rename split(text,text,int) to splitpart
It seems that my last mail on this did not get through to the list ;( Please consider renaming the new builtin function split(text,text,int) to something else, perhaps split_part(text,text,int) (like date_part) The reason for this request is that 3 most popular scripting languages (perl, python, php) all have also a function with similar signature, but returning an array instead of single element and the (optional) third argument is limit (maximum number of splits to perform) I think that it would be good to have similar function in (some future release of) postgres, but if we now let in a function with same name and arguments but returning a single string instead an array of them, then we will need to invent a new and not so easy to recognise name for the "real" split function. Hannu ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] contrib/tsearch
Hi Oleg/Teodor, I'm sorry to keep posting bugs without patches, but I'm just hoping you guys know the answer faster than I...I know you're busy. What does tsearch have against the word 'herring' (as in the fish). Why is it considered a stopword? Attached is example queries... Chris usa=# select food_id, brand,description,ftiidx from food_foods where description ilike '%herring%'; food_id | brand | description | ftiidx -++--+- 66245 | Kosher/Deli Foods | Herring, Smoked | 'food' 'smoke' 'kosher/deli' 66246 | Kosher/Deli Foods | Herring, in Sour Cream | 'food' 'sour' 'cream' 'kosher/deli' 4590 | - Generic -| Fish oil, herring| 'oil' 'fish' 'gener' 70737 | - Average All Brands - | Finfish, herring, Pacific, raw | 'raw' 'brand' 'pacif' 'averag' 'finfish' 70738 | - Average All Brands - | Finfish, herring, Pacific, cooked, dry heat | 'dri' 'cook' 'heat' 'brand' 'pacif' 'averag' 'finfish' 70739 | - Average All Brands - | Finfish, herring, Atlantic, raw | 'raw' 'brand' 'atlant' 'averag' 'finfish' 70740 | - Average All Brands - | Finfish, herring, Atlantic, pickled | 'brand' 'pickl' 'atlant' 'averag' 'finfish' 70741 | - Average All Brands - | Finfish, herring, Atlantic, kippered | 'brand' 'atlant' 'averag' 'kipper' 'finfish' 70742 | - Average All Brands - | Finfish, herring, Atlantic, cooked, dry heat | 'dri' 'cook' 'heat' 'brand' 'atlant' 'averag' 'finfish' 66026 | German | Herring, Pickled: Rollmops | 'pickl' 'german' 'rollmop' 66027 | German | Herring, Pickled: w/Sour Cream | 'cream' 'pickl' 'german' 'w/sour' (11 rows) usa=# select food_id, brand,description,ftiidx from food_foods where ftiidx ## 'herring'; NOTICE: Query contains only stopword(s) or doesn't contain lexem(s), ignored food_id | brand | description | ftiidx -+---+-+ (0 rows) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] contrib/tsearch
Hmmm...thinking about it, maybe 'herring' is being reduced to 'her' after the stemming process and hence is thought to be a stopword? This is a bug, but how should it be fixed? Although, tests don't support that: usa=# select food_id, brand,description,ftiidx from food_foods where ftiidx ## 'himring'; food_id | brand | description | ftiidx -+---+-+ (0 rows) usa=# select food_id, brand,description,ftiidx from food_foods where ftiidx ## 'hisring'; food_id | brand | description | ftiidx -+---+-+ (0 rows) usa=# select food_id, brand,description,ftiidx from food_foods where ftiidx ## 'hising'; food_id | brand | description | ftiidx -+---+-+ (0 rows) usa=# select food_id, brand,description,ftiidx from food_foods where ftiidx ## 'himing'; food_id | brand | description | ftiidx -+---+-+ (0 rows) All work...? Chris > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Christopher > Kings-Lynne > Sent: Thursday, 5 September 2002 2:36 PM > To: Hackers > Subject: [HACKERS] contrib/tsearch > > > Hi Oleg/Teodor, > > I'm sorry to keep posting bugs without patches, but I'm just > hoping you guys > know the answer faster than I...I know you're busy. > > What does tsearch have against the word 'herring' (as in the > fish). Why is > it considered a stopword? > > Attached is example queries... > > Chris > ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Inheritance
On Thu, 2002-09-05 at 03:57, Curt Sampson wrote: > On Tue, 3 Sep 2002, Bruce Momjian wrote: > > > Yep, this is where we are stuck; having an index span multiple tables > > in some way. > > Or implementing it by keeping all data in the table in which it > was declared. (I.e., supertable holds all rows; subtable holds > only the primary key and those columns of the row that are not > in the supertable.) How would you do it for _multiple_ inheritance ? When implementing it on top of standard relational model you have more or less two ways to slice the problem 1) the way you describe (parent holding common columns + child tables for added child columns), which makes it easy to define constraints but hard to do inserts/updates/deletes on inherited tables 2) the postgresql way (a new table for each child), which makes it hard to define constraints but easy to do inserts/updates/deletes. > From looking at the various discussions of this in books, and what > it appears to me that the SQL standard says, it seems that their > overall vision of table inheritance is to be consistent with the > implementation that I described above. Yes. The SQL99 standard specifies only _single_ inheritance for tables + LIKE in column definition part, making the model somewhat similar to Java's (single inheritance + interfaces). This way it could probably be done even more effectively than you describe by: 1) keeping _all_ (not only the inherited columns) the data for inheritance hierarchy in the same physical file. 2) having partial indexes (involving tableoid=thiskindoftable) for possible speeding up of SELECT .. ONLY queries. 3) no changes to (unique) indexes - they still reference simple TID's without additional table part. 4) update/delete of all child tables are trivial as they are actually done in the same table and not using joins It seems that single inheritance avoids other conceptual problems, like what to do with primary keys when inheriting from two tables that have them. Hannu ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
