Re: [HACKERS] RPMS for 7.3 beta.
On Wed, 2002-09-18 at 05:02, Bruce Momjian wrote: Oliver Elphick wrote: I'm unhappy because I know that I will get bug reports that I will have to deal with. They will take time and effort and would not be necessary if we had a seamless upgrade path. This last line gave me a chuckle. It is like software wouldn't be necessary if computers could read people's minds. :-) Not really! We know what the formats are before and after. We want PostgreSQL to be the best database. Why on earth can we not have the same ambition for the upgrade process? -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C Give, and it shall be given unto you; good measure, pressed down, and shaken together, and running over, shall men pour into your lap. For by your standard of measure it will be measured to in return. Luke 6:38 ---(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] Open 7.3 items
There has been a lot of activity on open items in the past week. Here is the updated list. Basically, upgrading and casting have blown up into a variety of items. What's the timeframe for beta2? FreeBSD's going into a ports freeze on Friday and I'd be slick to see it ship with 7.3beta2. 'nother few weeks before beta2 or is it right around the corner? For those interested in PostgreSQL + FreeBSD, I have a patch pending approval that will let developers toggle between a devel port and the stable release for all ports that depend on PostgreSQL. -sc -- Sean Chittenden ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Backend crash (long)
Hi all,
I have written a test function, that will create a sequence and a table,
than insert one million rows into the table, analyze the table and create an
index on one of the columns.
(so this will all happen inside on transaction)
After doing that, the backend will crash.
(but the data will be inserted)
If I comment out the table analyzing and the create index (I have not tested
which on leads to the crash), everything works fine. I have sent a copy of
the error log, the psql session, the function and some parts of my
postgresql.conf file.
My system is RedHat 7.2, Kernel 2.4.9-34, glibc-2.2.4, gcc 2.96, PostgreSQL
7.2.2 built from source.
If you want, I could try other combinations of create/insert/analyze etc. to
test the exact steps needed to crash the backend.
I know what I am doing is not really standard. This was rather a stability
test of postgres :). What do you think about this all?
Best Regards,
Michael Paesold
-- logfile:
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
'bench_big_pkey' for table 'bench_big'
DEBUG: recycled transaction log file 009F
[...skipping: recycled transaction log file 00A0 to
00AE]
DEBUG: recycled transaction log file 00B0
DEBUG: Analyzing bench_big
DEBUG: server process (pid 13840) was terminated by signal 11
DEBUG: terminating any other active server processes
DEBUG: all server processes terminated; reinitializing shared memory and
semaphores
DEBUG: database system was interrupted at 2002-09-17 11:45:56 CEST
DEBUG: checkpoint record is at 0/B41170A4
DEBUG: redo record is at 0/B400DF34; undo record is at 0/0; shutdown FALSE
DEBUG: next transaction id: 96959; next oid: 6282462
DEBUG: database system was not properly shut down; automatic recovery in
progress
DEBUG: redo starts at 0/B400DF34
DEBUG: ReadRecord: record with zero length at 0/B495F754
DEBUG: redo done at 0/B495F730
DEBUG: recycled transaction log file 00B2
DEBUG: recycled transaction log file 00B1
DEBUG: recycled transaction log file 00B3
DEBUG: database system is ready
The first time I tried the insert, there was an additional notice from
another backend, just after the line DEBUG: terminating any other active
server processes:
NOTICE: Message from PostgreSQL backend:
The Postmaster has informed me that some other backend
died abnormally and possibly corrupted shared memory.
I have rolled back the current transaction and am
going to terminate your database system connection and exit.
Please reconnect to the database system and repeat your query.
-- in psql:
billing=# select create_benchmark ();
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
'bench_big_pkey' for table 'bench_big'
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!# \c
Password:
You are now connected to database billing as user billing.
billing=# select real_time from bench_big where int_id in (1, 100);
real_time
---
2002-09-17 11:32:22.63334+02
2002-09-17 11:46:16.601282+02
(2 rows)
-- all rows have definatly been inserted!
-- the trigger function:
CREATE OR REPLACE FUNCTION create_benchmark () RETURNS BOOLEAN AS '
DECLARE
char100 VARCHAR :=
\'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZäöüÄÖÜß1234567890!§$%
/()=?+*#|-_,;.:^°{}´`[]\';
r1 INTEGER;
r2 INTEGER;
r3 INTEGER;
BEGIN
CREATE SEQUENCE bench_seq;
CREATE TABLE bench_big (
int_id INTEGER NOT NULL default nextval(\'bench_seq\'),
bigint_id BIGINT NOT NULL,
sometext1 VARCHAR (50),
sometext2 VARCHAR (50),
sometext3 VARCHAR (50),
trx_time TIME WITHOUT TIME ZONE NOT NULL default CURRENT_TIME,
trx_timestamp TIMESTAMP WITHOUT TIME ZONE NOT NULL default
CURRENT_TIMESTAMP,
trx_date DATE NOT NULL default CURRENT_DATE,
real_time TIMESTAMP NOT NULL default timeofday(),
someboolean1 BOOLEAN NOT NULL,
someboolean2 BOOLEAN NOT NULL,
PRIMARY KEY (int_id)
);
FOR i IN 1..100 LOOP
r1 = CAST( RANDOM() * 49 AS INTEGER );
r2 = CAST( RANDOM() * 49 AS INTEGER );
r3 = CAST( RANDOM() * 49 AS INTEGER );
INSERT INTO bench_big
(bigint_id, sometext1, sometext2, sometext3, someboolean1,
someboolean2)
VALUES (
CAST(RANDOM() * 100 AS BIGINT),
SUBSTR(char100, 50, 49), -- this should be r1, r1 (but doesn't work!)
SUBSTR(char100, 50, 49), -- this should be r2, r2 (but doesn't work!)
SUBSTR(char100, 50, 49), -- this should be r3, r3 (but doesn't work!)
CASE WHEN r1 25 THEN TRUE ELSE FALSE END,
CASE WHEN r3 10 THEN TRUE ELSE FALSE END
);
END LOOP;
-- WARNING: un-commenting these lines could crash your postgres
-- CREATE INDEX bench_bigint_id_idx ON bench_big(bigint_id);
--
[HACKERS] CVsup file
Hello, Does anyone have a CURRENT cvsup file for 7.3? I tried to follow the link on the developer website and it comes up 404. I've got one for 7.2-STABLE, but it is old and does not include the stuff that was broken out. BTW, I've install the 7.3-BETA, and so far everything is working the way it should on FreeBSD 4.6-STABLE. Thanks! GB -- GB Clark II | Roaming FreeBSD Admin [EMAIL PROTECTED] | General Geek CTHULU for President - Why choose the lesser of two evils? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] please apply patch to contrib/ltree
Tiny patch fixing small documentation typo. Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 *** contrib/ltree/README.ltree Sun Aug 11 00:46:24 2002 --- README.ltree.newWed Sep 18 13:08:27 2002 *** *** 144,154 * GiST index over ltree: , =, =, =, , @, @, @, ~ Example: ! create index path_gist_idx on test using gist_ltree_ops (path); * GiST index over ltree[]: ltree[]@ ltree, ltree @ ltree[], @, ~. Example: ! create index path_gist_idx on test using gist__ltree_ops (array_path); Notices: This index is lossy. FUNCTIONS --- 144,154 * GiST index over ltree: , =, =, =, , @, @, @, ~ Example: ! create index path_gist_idx on test using gist (path); * GiST index over ltree[]: ltree[]@ ltree, ltree @ ltree[], @, ~. Example: ! create index path_gist_idx on test using gist (array_path); Notices: This index is lossy. FUNCTIONS ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] genetic algorithm in PostgreSQL
Hello, I am Spanish student of Computer Science. I have read through the part of the postgreSQL documentacion about genetic query optimization in PostgreSQL. I am following a Genetic Algorithms course at my University. I have to do an assigment giving an example of optimization with genetic algorithms, and my teacher suggested me to do it using databases, but actually he does not know very much about this. I have done some kind of research from the references given in the docs and get as much information I had available (mostly from the Berkeley web site), but I dont get examples and information for a newbie in this kind of matters. I would like to know if you have any sample program, or simple query optimization which I could start playing around with, to show the optimization posibilities of genetic algorithms in PostgreSQL. If this is not possible, If you dont mind please give me any further links that could be interesting for me. Many thanks in advance. Miguel ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] unaccent
Greetings, As far as I use the txtidx data structure in conjunction with gist indexing to make a word indexing of a very large UNICODE db, I've implemented a PostgreSQL function that uses libunac to unaccent TEXT fileds. The resulting text is in UTF-8, but you can modify it in the sources with an appropriate value (using iconv charset names). Get libunac from: http://www.nongnu.org/unac/ (it uses iconv) Extract the archive, compile it (make). Move pg_unac.so to your postgresql shared libraries dir. Link it in postgresql: CREATE FUNCTION unac(TEXT) RETURNS TEXT AS 'path_to_pg_unac.so' LANGUAGE C; What about integrating unaccent libraries directly in tsearch? It is useful for french search engines (for instance). Bye. Nhan NGO DINH __ Tiscali Ricaricasa la prima prepagata per navigare in Internet a meno di un'urbana e risparmiare su tutte le tue telefonate. Acquistala on line e non avrai nessun costo di attivazione né di ricarica! http://ricaricasaonline.tiscali.it/ pg_unac-1.0.tar.gz Description: application/gzip-compressed ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] strip a character from text
Greetings, Does anyone know a function that strips ANY occurence of a given character from a TEXT? Thx. Nhan NGO DINH __ Tiscali Ricaricasa la prima prepagata per navigare in Internet a meno di un'urbana e risparmiare su tutte le tue telefonate. Acquistala on line e non avrai nessun costo di attivazione né di ricarica! http://ricaricasaonline.tiscali.it/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] unaccent
On Wed, 18 Sep 2002 [EMAIL PROTECTED] wrote: Greetings, As far as I use the txtidx data structure in conjunction with gist indexing to make a word indexing of a very large UNICODE db, I've implemented a PostgreSQL function that uses libunac to unaccent TEXT fileds. The resulting text is in UTF-8, but you can modify it in the sources with an appropriate value (using iconv charset names). Get libunac from: http://www.nongnu.org/unac/ (it uses iconv) Extract the archive, compile it (make). Move pg_unac.so to your postgresql shared libraries dir. Link it in postgresql: CREATE FUNCTION unac(TEXT) RETURNS TEXT AS 'path_to_pg_unac.so' LANGUAGE C; What about integrating unaccent libraries directly in tsearch? It is useful for french search engines (for instance). I think better to have separate module contrib/unac and document using it with tsearch. Please write us a couple of lines about using your function and we'll add them into tsearch documentation. btw, use palloc instead of malloc in postgresql functions . Bye. Nhan NGO DINH __ Tiscali Ricaricasa la prima prepagata per navigare in Internet a meno di un'urbana e risparmiare su tutte le tue telefonate. Acquistala on line e non avrai nessun costo di attivazione né di ricarica! http://ricaricasaonline.tiscali.it/ Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(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] RPMS for 7.3 beta.
Remember that Rod Taylor's written a script to fix at least the foreign key issue above. I think it'd be neat if that script were perfected and did serials as well and then we could recommend its use... It does do serials (adds pg_depend entry -- which is just enough), as well as changes unique indexes into unique constraints. As I had a few items I didn't want to upgrade, it asks the user if they want to do each one (-Y to fix 'em all). -- Rod Taylor ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] strip a character from text
On Wed, 2002-09-18 at 11:18, [EMAIL PROTECTED] wrote: Greetings, Does anyone know a function that strips ANY occurence of a given character from a TEXT? It sounds like a job for a PL/Perl function. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C Give, and it shall be given unto you; good measure, pressed down, and shaken together, and running over, shall men pour into your lap. For by your standard of measure it will be measured to in return. Luke 6:38 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] unaccent
The best way to use it is quite simple. If you want to index the table titles and title is the field containing the text to be indexed, you can create another unaccented field, for instance utitle. UPDATE titles SET utitle = unac(title); Of course you can set it up as a trigger function. Then you can use utitle with txt2txtidx and tsearch. Another solution is to generate the txtidx field (i.e. titleidx) directly using unac: UPDATE titles SET titleidx = txt2txtidx(unac(title)); But the problem is that I've not succeeded using it with tsearch because (of course) it doesn't allow functions as parameters. So my first idea was to integrate unac in tsearch. Bye. -- Messaggio Originale -- Date: Wed, 18 Sep 2002 15:08:59 +0300 (GMT) From: Oleg Bartunov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] unaccent On Wed, 18 Sep 2002 [EMAIL PROTECTED] wrote: Greetings, As far as I use the txtidx data structure in conjunction with gist indexing to make a word indexing of a very large UNICODE db, I've implemented a PostgreSQL function that uses libunac to unaccent TEXT fileds. The resulting text is in UTF-8, but you can modify it in the sources with an appropriate value (using iconv charset names). Get libunac from: http://www.nongnu.org/unac/ (it uses iconv) Extract the archive, compile it (make). Move pg_unac.so to your postgresql shared libraries dir. Link it in postgresql: CREATE FUNCTION unac(TEXT) RETURNS TEXT AS 'path_to_pg_unac.so' LANGUAGE C; What about integrating unaccent libraries directly in tsearch? It is useful for french search engines (for instance). I think better to have separate module contrib/unac and document using it with tsearch. Please write us a couple of lines about using your function and we'll add them into tsearch documentation. btw, use palloc instead of malloc in postgresql functions . Bye. Nhan NGO DINH __ Tiscali Ricaricasa la prima prepagata per navigare in Internet a meno di un'urbana e risparmiare su tutte le tue telefonate. Acquistala on line e non avrai nessun costo di attivazione n? di ricarica! http://ricaricasaonline.tiscali.it/ Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(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 __ Tiscali Ricaricasa la prima prepagata per navigare in Internet a meno di un'urbana e risparmiare su tutte le tue telefonate. Acquistala on line e non avrai nessun costo di attivazione né di ricarica! http://ricaricasaonline.tiscali.it/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] unaccent
Not to_ascii, since there are so many extended UNICODE characters that doesn't have any accent and should not be converted to an ASCII character. -- Messaggio Originale -- Date: Wed, 18 Sep 2002 14:24:26 +0200 From: Karel Zak [EMAIL PROTECTED] To: Oleg Bartunov [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [HACKERS] unaccent On Wed, Sep 18, 2002 at 03:08:59PM +0300, Oleg Bartunov wrote: On Wed, 18 Sep 2002 [EMAIL PROTECTED] wrote: Get libunac from: http://www.nongnu.org/unac/ (it uses iconv) Extract the archive, compile it (make). Move pg_unac.so to your postgresql shared libraries dir. I think better to have separate module contrib/unac and document using it with tsearch. Please write us a couple of lines about using your function and we'll add them into tsearch documentation. I think about --with-unaccent for PostgreSQL and to_ascii() in main tree. Comment? Karel -- Karel Zak [EMAIL PROTECTED] http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org __ Tiscali Ricaricasa la prima prepagata per navigare in Internet a meno di un'urbana e risparmiare su tutte le tue telefonate. Acquistala on line e non avrai nessun costo di attivazione né di ricarica! http://ricaricasaonline.tiscali.it/ ---(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] strip a character from text
I'm about to write a C function... If I can't found alternatives. -- Messaggio Originale -- Subject: Re: [HACKERS] strip a character from text From: Oliver Elphick [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Date: 18 Sep 2002 13:30:49 +0100 On Wed, 2002-09-18 at 11:18, [EMAIL PROTECTED] wrote: Greetings, Does anyone know a function that strips ANY occurence of a given character from a TEXT? It sounds like a job for a PL/Perl function. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C Give, and it shall be given unto you; good measure, pressed down, and shaken together, and running over, shall men pour into your lap. For by your standard of measure it will be measured to in return. Luke 6:38 __ Tiscali Ricaricasa la prima prepagata per navigare in Internet a meno di un'urbana e risparmiare su tutte le tue telefonate. Acquistala on line e non avrai nessun costo di attivazione né di ricarica! http://ricaricasaonline.tiscali.it/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] unaccent
On Wed, 18 Sep 2002, Karel Zak wrote: On Wed, Sep 18, 2002 at 03:08:59PM +0300, Oleg Bartunov wrote: On Wed, 18 Sep 2002 [EMAIL PROTECTED] wrote: Get libunac from: http://www.nongnu.org/unac/ (it uses iconv) Extract the archive, compile it (make). Move pg_unac.so to your postgresql shared libraries dir. I think better to have separate module contrib/unac and document using it with tsearch. Please write us a couple of lines about using your function and we'll add them into tsearch documentation. I think about --with-unaccent for PostgreSQL and to_ascii() in main tree. Comment? Hmm, it'd require linking yet another library. contrib module is a standard way to test/develope possible future feature. Karel Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] The notorious to_char bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (From the SQL list:) And we know it is a bug: * to_char(0,'FM999.99') returns a period, to_char(1,'FM999.99') does not I took a look at this bug a week ago, and noticed that inside of the file src/backend/utils/adt/formatting.c we are specifically causing the above behavior, perhaps in an effort to mimic Oracle's implementation of it. Unless I am missing something, it seems that we can simply take out the hack inside of the above file, or mark the bug as solved... Search for the strings terrible and terible to find the spots inside of formatting.c Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200209180909 -BEGIN PGP SIGNATURE- iD8DBQE9iIDvvJuQZxSWSsgRAqRLAJ9gV8oTnMFTsSmQzMdKppNlWW/TvACgvDu2 f0TDVbi//F5jwZn7K9+9wLE= =TIs7 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RPMS for 7.3 beta.
Lamar Owen [EMAIL PROTECTED] writes: On Wednesday 18 September 2002 12:55 am, Tom Lane wrote: But the system catalogs *store* that metadata. They _currently_ store the user's metadata. But that's my point -- does the user metadata that isn't typically substantially different after going through a dump/reload _have_ to coexist with the system data which is intrinsic to the basic backend operation? I think we're talking at cross-purposes. When I said we can't freeze the system catalogs yet, I meant that we cannot freeze the format/schema in which metadata is stored. That affects both system and user entries. You seem to be envisioning moving user metadata into a separate set of tables from the predefined entries --- but that will help not one whit as far as easing upgrades goes. Given the desireability for opaque to go away soon, if the 7.3 pg_dump Does The Right Thing and creates an opaque-free dump, The present proposal for that has the 7.3 backend patching things up during reload; it won't matter whether you use 7.2 or 7.3 pg_dump to dump from a 7.2 database. And it may prove to not be that bad -- I'll know in a few days, hopefully. If you find that it's not too painful then I do agree with doing it. There will doubtless be future cycles where it's more valuable to be able to use the up-to-date pg_dump than it is in this one. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] unaccent
The txt2txtidx function works fine with unac. The problem is with the trigger: create trigger txtidxupdate before update or insert on titles for each row execute procedure tsearch(titleidx, title); As you know tsearch(titleidx, unac(title)) doesn't work. -- Messaggio Originale -- Date: Wed, 18 Sep 2002 17:04:56 +0300 (GMT) From: Oleg Bartunov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] unaccent On Wed, 18 Sep 2002 [EMAIL PROTECTED] wrote: The best way to use it is quite simple. If you want to index the table titles and title is the field containing the text to be indexed, you can create another unaccented field, for instance utitle. UPDATE titles SET utitle = unac(title); Of course you can set it up as a trigger function. Then you can use utitle with txt2txtidx and tsearch. Another solution is to generate the txtidx field (i.e. titleidx) directly using unac: UPDATE titles SET titleidx = txt2txtidx(unac(title)); But the problem is that I've not succeeded using it with tsearch because (of course) it doesn't allow functions as parameters. So my first idea was to integrate unac in tsearch. what's exactly a problem ? UPDATE titles SET titleidx = txt2txtidx(unac(title)); works fine. Perhaps, you have a problem with query ? Bye. -- Messaggio Originale -- Date: Wed, 18 Sep 2002 15:08:59 +0300 (GMT) From: Oleg Bartunov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] unaccent On Wed, 18 Sep 2002 [EMAIL PROTECTED] wrote: Greetings, As far as I use the txtidx data structure in conjunction with gist indexing to make a word indexing of a very large UNICODE db, I've implemented a PostgreSQL function that uses libunac to unaccent TEXT fileds. The resulting text is in UTF-8, but you can modify it in the sources with an appropriate value (using iconv charset names). Get libunac from: http://www.nongnu.org/unac/ (it uses iconv) Extract the archive, compile it (make). Move pg_unac.so to your postgresql shared libraries dir. Link it in postgresql: CREATE FUNCTION unac(TEXT) RETURNS TEXT AS 'path_to_pg_unac.so' LANGUAGE C; What about integrating unaccent libraries directly in tsearch? It is useful for french search engines (for instance). I think better to have separate module contrib/unac and document using it with tsearch. Please write us a couple of lines about using your function and we'll add them into tsearch documentation. btw, use palloc instead of malloc in postgresql functions . Bye. Nhan NGO DINH __ Tiscali Ricaricasa la prima prepagata per navigare in Internet a meno di un'urbana e risparmiare su tutte le tue telefonate. Acquistala on line e non avrai nessun costo di attivazione n? di ricarica! http://ricaricasaonline.tiscali.it/ Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(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 __ Tiscali Ricaricasa la prima prepagata per navigare in Internet a meno di un'urbana e risparmiare su tutte le tue telefonate. Acquistala on line e non avrai nessun costo di attivazione n? di ricarica! http://ricaricasaonline.tiscali.it/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org __ Tiscali Ricaricasa la prima prepagata per navigare in Internet a meno di un'urbana e risparmiare su tutte le tue telefonate. Acquistala on line e non avrai nessun costo di attivazione né di ricarica! http://ricaricasaonline.tiscali.it/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Backend crash (long)
Michael Paesold [EMAIL PROTECTED] writes: I have written a test function, that will create a sequence and a table, than insert one million rows into the table, analyze the table and create an index on one of the columns. You can't run ANALYZE inside a function. In CVS tip there's a check to prevent the VACUUM variant of this problem, but I'm not sure if it handles the ANALYZE variant (yet). regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Backend crash (long)
On Wed, 2002-09-18 at 11:03, Tom Lane wrote: Michael Paesold [EMAIL PROTECTED] writes: I have written a test function, that will create a sequence and a table, than insert one million rows into the table, analyze the table and create an index on one of the columns. You can't run ANALYZE inside a function. In CVS tip there's a check to prevent the VACUUM variant of this problem, but I'm not sure if it handles the ANALYZE variant (yet). ANALYZE in 7.3 works fine in a transaction, so it shouldn't it be able to work in a function as well? rbt=# begin; BEGIN rbt=# analyze; ANALYZE rbt=# commit; COMMIT rbt=# create function test() returns bool as 'analyze; select true;' language 'sql'; CREATE FUNCTION rbt=# select test(); test -- t (1 row) -- Rod Taylor ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Backend crash (long)
Rod Taylor [EMAIL PROTECTED] writes: On Wed, 2002-09-18 at 11:03, Tom Lane wrote: Michael Paesold [EMAIL PROTECTED] writes: I have written a test function, that will create a sequence and a table, than insert one million rows into the table, analyze the table and create an index on one of the columns. You can't run ANALYZE inside a function. In CVS tip there's a check to prevent the VACUUM variant of this problem, but I'm not sure if it handles the ANALYZE variant (yet). ANALYZE in 7.3 works fine in a transaction, so it shouldn't it be able to work in a function as well? Possibly it's okay in 7.3; I have a note to look at that, but haven't done it yet. I think REINDEX has the same problem btw ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Proposal for resolving casting issues
Note that if you write, say, set numericcol = numericcol * 3.14159; my proposal would do the right thing since the constant would be typed as numeric to start with and would stay that way. To do what you want with a float variable, it'd be necessary to write set numericcol = numericcol * float4col::numeric; Yes, that is the case where the new behavior would imho not be good (but you say spec compliant). I loose precision even though there is room to hold it. which is sort of ugly; but no uglier than set float4col = float4col * numericcol::float4; Informix does the calculations in numeric, and then converts the result if no casts are supplied (would do set float4col = float4(float4col::numeric * numericcol)). Would be interesting what others do ? Test script: create table atab (a decimal(30), b smallfloat, c decimal(30), d smallfloat); insert into atab values (1.001,10.0,0, 0); update atab set c=a*b-b, d=a*b-b where 1=1; select a*b-b, b, c,d from atab; (expression) bc d 1e-10 10.0001e-10 1e-10 I hope this test is ok ? It still seems to me, that numeric should be the preferred type, and not float8. Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Proposal for resolving casting issues
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes: Note that if you write, say, set numericcol = numericcol * 3.14159; my proposal would do the right thing since the constant would be typed as numeric to start with and would stay that way. To do what you want with a float variable, it'd be necessary to write set numericcol = numericcol * float4col::numeric; Yes, that is the case where the new behavior would imho not be good (but you say spec compliant). I loose precision even though there is room to hold it. Lose what precision? It seems silly to imagine that the product of a numeric and a float4 is good to more digits than there are in the float4. This is exactly the spec's point: combining an exact and an approximate input will give you an approximate result. (Unless of course the value in the float4 happens to be exact, eg, an integer of not very many digits. But if you are relying on that to be true, why aren't you using an exact format for storing it?) Informix does the calculations in numeric, and then converts the result if no casts are supplied (would do set float4col = float4(float4col::numeric * numericcol)). I am not sure what the argument is for following Informix's lead rather than the standard's lead; especially when Informix evidently doesn't understand numerical analysis ;-) 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] strip a character from text
[EMAIL PROTECTED] wrote:
I'm about to write a C function... If I can't found alternatives.
Note that in 7.3 (in beta now) there is a new replace() function which will do
this:
regression=# select replace('abcdefghabcdef','c','');
replace
--
abdefghabdef
Joe
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RPMS for 7.3 beta.
I am working on a README and will add this to /contrib. Thanks. --- Rod Taylor wrote: Using 7.3's pg_dump would help you with the GRANT issue, but AFAIR it won't do anything for reconstructing serial or foreign-key dependencies. The below perl script can help with both of those. http://www.rbt.ca/postgresql/upgrade/upgrade.tar.gz Explanation URL: http://www.rbt.ca/postgresql/upgrade.shtml Doesn't deal with DEFERRED triggers. -- Rod Taylor ---(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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] The notorious to_char bug
Oracle 8.1.7.2 SQL SELECT to_char(0,'FM999.99') AS tst_char FROM dual; TST_CHA --- 0. SQL SELECT to_char(1,'FM999.99') AS tst_char FROM dual; TST_CHA --- 1. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tom Lane Sent: Wednesday, September 18, 2002 9:12 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] The notorious to_char bug [EMAIL PROTECTED] writes: (From the SQL list:) And we know it is a bug: * to_char(0,'FM999.99') returns a period, to_char(1,'FM999.99') does not I took a look at this bug a week ago, and noticed that inside of the file src/backend/utils/adt/formatting.c we are specifically causing the above behavior, perhaps in an effort to mimic Oracle's implementation of it. Hm. Can anyone try these cases on Oracle? If the code goes out of its way to have this odd behavior, maybe it's because Oracle does too. 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 ---(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] RPMS for 7.3 beta.
Sounds good. I think the earliest we could be ready for beta2 is the end of this week; sometime next week may be more realistic. Given that we'll be forcing an initdb for beta2 anyway, those who use RPMs may be just as happy to have missed beta1. If an initdb is planned - did that split-split_part or whatever change make it in? Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] RPMS for 7.3 beta.
Christopher Kings-Lynne wrote: Sounds good. I think the earliest we could be ready for beta2 is the end of this week; sometime next week may be more realistic. Given that we'll be forcing an initdb for beta2 anyway, those who use RPMs may be just as happy to have missed beta1. If an initdb is planned - did that split-split_part or whatever change make it in? Yes, it did, and in fact if you didn't initdb after the patch was applied, you would see regression failures. -- 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] Proposal for resolving casting issues
Bruce Momjian writes: Or possibly it should be AS IMPLICIT? I think AS IMPLICIT would be better because we have other AS [var] clauses. But IMPLICIT is not a variable. -- Peter Eisentraut [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
Re: [HACKERS] RPMS for 7.3 beta.
Oliver Elphick writes: We want PostgreSQL to be the best database. Why on earth can we not have the same ambition for the upgrade process? We do have that ambition. We just don't have enough clues and time to follow up on it. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 items
Bruce Momjian writes: There has been a lot of activity on open items in the past week. Here is the updated list. SIMILAR TO and the associated SUBSTRING functionality need to be fixed. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Inconsistent Conversion Names
I thought you had named the conversion functions after the IANA names. I found the following inconsistencies, however: sjis should be shift_jis win1250 should be windows_1250 (similarly 866, 1251) koi8r should be koi8_r I think we should fix this now. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] BLOB
On Wed, 2002-09-18 at 18:32, Manuel Cabido wrote: Hi PostgreSQL Folks, I would like to inquire how is the BLOB support in PostgreSQL is doing now? Had there been some improvements? Can I have the blob support like in I'm unsure about blob (didn't know we had a blob type), but bytea works perfectly fine for that. -- Rod Taylor ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Restore from pre-v7.3 - v7.3 (Was: Re: [HACKERS] RPMS for 7.3 beta.)
On Tue, 17 Sep 2002, Tom Lane wrote: I am waiting the result of the pg_dump from 7.2.x to 7.3 restore discussion. Right. We clearly have to support loading of 7.2 dumps; the only issue in my mind is exactly how we kluge that up ;-). I just talked to Bruce about this a little bit, and we came to the conclusion that there are two plausible-looking paths: 1. Relax CREATE LANGUAGE to accept either LANGUAGE_HANDLER or OPAQUE as the datatype of the function (ie, make it work more like CREATE TRIGGER does). 2. Hack CREATE LANGUAGE so that if it's pointed at an OPAQUE-returning function, it actually updates the recorded return type of the function in pg_proc to say LANGUAGE_HANDLER. Stupid question, but why not just create an upgrade script that does any required translations external to the database? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items
Gavin Sherry wrote: Change log_min_error_statement to be off by default (Gavin) I will be happy to provide this simple fix once I can get some indication of the preferred implication. The discussion left off with Bruce prefering that the GUC code for the *_min_* variables be variable specific where as Tom saw no need to back out the generic assignment function I provided, despite the fact that it behaves `illogically' (client_min_messages = FATAL?). Thanks, Gavin. Tom convinced me that it was OK to have illogical values. Also, I think we need to support PANIC for server_min_messages anyway to use as a default value for 'off'. Does that make sense? -- 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] Open 7.3 items
Sean Chittenden wrote: There has been a lot of activity on open items in the past week. Here is the updated list. Basically, upgrading and casting have blown up into a variety of items. What's the timeframe for beta2? FreeBSD's going into a ports freeze on Friday and I'd be slick to see it ship with 7.3beta2. 'nother few weeks before beta2 or is it right around the corner? For those interested in PostgreSQL + FreeBSD, I have a patch pending approval that will let developers toggle between a devel port and the stable release for all ports that depend on PostgreSQL. I have heard end of this week or next week for beta2. Also, plan was to split the CVS tree at that time. -- 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])
Re: [HACKERS] please apply patch to contrib/ltree
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Oleg Bartunov wrote: Tiny patch fixing small documentation typo. Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 Content-Description: [ Attachment, skipping... ] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Proposal for resolving casting issues
Peter Eisentraut wrote: Bruce Momjian writes: Or possibly it should be AS IMPLICIT? I think AS IMPLICIT would be better because we have other AS [var] clauses. But IMPLICIT is not a variable. I meant we have cases where we do AS [ keyword1 | keyword2 ]. CREATE OPERATOR CLASS any_name opt_default FOR TYPE_P Typename USING access_method AS opclass_item_list What I am saying is that is better to do AS [ keyword | keyword ] rather than [ AS keyword | keyword ]. -- 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] Proposal for resolving casting issues
Bruce Momjian [EMAIL PROTECTED] writes: What I am saying is that is better to do AS [ keyword | keyword ] rather than [ AS keyword | keyword ]. Yeah, I thought the same after looking at it a little. Committed that way (of course it's still open to adjustment...) 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] Open 7.3 items
Thomas Lockhart wrote: ... Fix SIMILAR TO to be Posix compiant or remove it Sorry, was there a decision here? No one has described the problem, just declared that there is one and declared that the feature should be removed. In the old days, one might have expected to approach this differently, with a contribution to help fix a problem, after describing it. I'm not quite understanding the current process, if there is one. I had it in my mailbox as an unresolved issue. Peter wanted it added so I did it. I don't know the issue either. If you want it removed from open item, I will do that too. -- 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]
[HACKERS] Win32 rename()/unlink() questions
I am working with several groups getting the Win32 port ready for 7.4 and I have a few questions: What is the standard workaround for the fact that rename() isn't atomic on Win32? Do we need to create our own locking around the reading/writing of files that are normally updated in place using rename()? Second, when you unlink() a file on Win32, do applications continue accessing the old file contents if they had the file open before the unlink? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] [HACKERS] PGXLOG variable worthwhile?
On Tue, 17 Sep 2002, Bruce Momjian wrote: Dave Page wrote: Which in this case is what puzzles me. We are only talking about a simple GUC variable after all - I don't know for sure, but I'm guessing it's not a huge effort to add one? Can we get agreement on that? A GUC for pg_xlog location? Much cleaner than -X, doesn't have the problems of possible accidental use, and does allow pg_xlog moving without symlinks, which some people don't like? If I can get a few 'yes' votes I will add it to TODO and do it for 7.4. Personally, I like the ability to define such at a command line level ... *especially* as it pertains to pointing to various directories ... I am against pulling the -X functionality out ... if you don't like it, don't use it ... add the GUC variable option to the mix, but don't take away functionality ... Hell, take a look at what you are saying above: because someone might forget to set -X, let's get rid of it in favor of a setting in a file that someone might forget to edit? Either format has the possibility of an error ... if you are so incompetent as to make that sort of mistake on a production server, it won't matter if its a GUC variable, environment variable or commnd line argument, you will still make that mistake ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] [HACKERS] PGXLOG variable worthwhile?
Marc G. Fournier wrote: On Tue, 17 Sep 2002, Bruce Momjian wrote: Dave Page wrote: Which in this case is what puzzles me. We are only talking about a simple GUC variable after all - I don't know for sure, but I'm guessing it's not a huge effort to add one? Can we get agreement on that? A GUC for pg_xlog location? Much cleaner than -X, doesn't have the problems of possible accidental use, and does allow pg_xlog moving without symlinks, which some people don't like? If I can get a few 'yes' votes I will add it to TODO and do it for 7.4. Personally, I like the ability to define such at a command line level ... *especially* as it pertains to pointing to various directories ... I am against pulling the -X functionality out ... if you don't like it, don't use it ... add the GUC variable option to the mix, but don't take away functionality ... Hell, take a look at what you are saying above: because someone might forget to set -X, let's get rid of it in favor of a setting in a file that someone might forget to edit? Either format has the possibility of an error ... if you are so incompetent as to make that sort of mistake on a production server, it won't matter if its a GUC variable, environment variable or commnd line argument, you will still make that mistake ... Sorry, I don't see the logic here. Using postgresql.conf, you set it once and it remains set until you change it again. With -X, you have to use it every time. I think that's where the votes came from. You argued that -X and GUC make sense, but why add -X when can get it done at once in postgresql.conf. Also, consider changing the location does require moving the WAL files, so you already have this extra step. Adding to postgresql.conf is easy. I don't think you can just point it at a random empty directory on startup. Our goal was to reduce params to postmaster/postgres in favor of GUC, not add to them. -- 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] Open 7.3 items
On Wed, 18 Sep 2002, Bruce Momjian wrote: On Going Point-in-time recovery Win32 port these have nothing to do with v7.3, so shouldn't even be listed here ... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 items
Marc G. Fournier wrote: On Wed, 18 Sep 2002, Bruce Momjian wrote: On Going Point-in-time recovery Win32 port these have nothing to do with v7.3, so shouldn't even be listed here ... OK, removed. -- 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
Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
On Wed, 18 Sep 2002, Sean Chittenden wrote: There has been a lot of activity on open items in the past week. Here is the updated list. Basically, upgrading and casting have blown up into a variety of items. What's the timeframe for beta2? FreeBSD's going into a ports freeze on Friday and I'd be slick to see it ship with 7.3beta2. 'nother few weeks before beta2 or is it right around the corner? I was actually going to post this tonight anyway ... its been 2 weeks, and since nobody should be committing anything but fixes (right guys?), I'm going to do up a beta2 on Friday due to the number changes that have been committed over the past 2 weeks ... Bruce, can you make sure that any changes needed prior to my packaging are done before noon ADT on Friday? I have no doubt that we have some outstanding issues to work through, but this will give a new checkpoint for those testing ... ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
Marc G. Fournier wrote: On Wed, 18 Sep 2002, Sean Chittenden wrote: There has been a lot of activity on open items in the past week. Here is the updated list. Basically, upgrading and casting have blown up into a variety of items. What's the timeframe for beta2? FreeBSD's going into a ports freeze on Friday and I'd be slick to see it ship with 7.3beta2. 'nother few weeks before beta2 or is it right around the corner? I was actually going to post this tonight anyway ... its been 2 weeks, and since nobody should be committing anything but fixes (right guys?), I'm going to do up a beta2 on Friday due to the number changes that have been committed over the past 2 weeks ... Bruce, can you make sure that any changes needed prior to my packaging are done before noon ADT on Friday? I have no doubt that we have some outstanding issues to work through, but this will give a new checkpoint for those testing ... We are going to require an initdb for beta2 and I think we need to get _everything_ required in there before going to beta2. See the open items list. I think we will need until the middle of next week for beta2. In fact, I have the inheritance patch that will require an initdb and that isn't even applied yet; Friday is too early. -- 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])
The TODO List (Was: Re: [HACKERS] Open 7.3 items)
On Wed, 18 Sep 2002, Bruce Momjian wrote: Thomas Lockhart wrote: ... Fix SIMILAR TO to be Posix compiant or remove it Sorry, was there a decision here? No one has described the problem, just declared that there is one and declared that the feature should be removed. In the old days, one might have expected to approach this differently, with a contribution to help fix a problem, after describing it. I'm not quite understanding the current process, if there is one. I had it in my mailbox as an unresolved issue. Peter wanted it added so I did it. I don't know the issue either. If you want it removed from open item, I will do that too. Well, if nobody can identify what exactly the problem is, it should definitely be removed from the Open Items list ... maybe we need to lay down some 'rules' for the TODO list? Some sort of criteria other hten someone suggested it to work with? For instance, change the TODO to a pseudo-FAQ format ... where an item added to it has to have some sort of 'associated' description? For instance, how is SIMILAR TO *not* Posix compliant? What *is* a Posix compliant version? Where is such compliance defined? Is there a reference? Also, since when has 'lack of compliance' been basis to remove something ... its not fully compliant, so even partial functionality isn't allowed? Basically, there should be *some* basis for an item to be on the TODO list ... some sort this is how it should be ... How many items on the TODO list are ones that nobody even knows what they are about anymore? :) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
On Wed, 18 Sep 2002, Bruce Momjian wrote: We are going to require an initdb for beta2 and I think we need to get _everything_ required in there before going to beta2. See the open items list. I think we will need until the middle of next week for beta2. In fact, I have the inheritance patch that will require an initdb and that isn't even applied yet; Friday is too early. We are in beta, not release ... the purpose of going to beta2 is to provide a new checkpoint to work bug reports off of, so having to deal with an initdb should not be considered a problem by anyone, since only a fool would run beta in production, no? (and ya, I am such a fool at times, but i do accept the fact that I am such *grin*) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: The TODO List (Was: Re: [HACKERS] Open 7.3 items)
Marc G. Fournier wrote: Well, if nobody can identify what exactly the problem is, it should definitely be removed from the Open Items list ... maybe we need to lay down some 'rules' for the TODO list? Some sort of criteria other hten someone suggested it to work with? For instance, change the TODO to a pseudo-FAQ format ... where an item added to it has to have some sort of 'associated' description? For instance, how is SIMILAR TO *not* Posix compliant? What *is* a Posix compliant version? Where is such compliance defined? Is there a reference? Also, since when has 'lack of compliance' been basis to remove something ... its not fully compliant, so even partial functionality isn't allowed? Basically, there should be *some* basis for an item to be on the TODO list ... some sort this is how it should be ... How many items on the TODO list are ones that nobody even knows what they are about anymore? :) I think you are confusing the open items list with the TODO list. TODO usually has some basis, while open items is just that, things we need to decide on. Peter brought it up and wanted it on the list so I put it on. I can be taken off just as easily. I put Peter's name on the item, and a question mark. The open items list is just so we don't forget things. -- 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: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
Marc G. Fournier wrote: On Wed, 18 Sep 2002, Bruce Momjian wrote: We are going to require an initdb for beta2 and I think we need to get _everything_ required in there before going to beta2. See the open items list. I think we will need until the middle of next week for beta2. In fact, I have the inheritance patch that will require an initdb and that isn't even applied yet; Friday is too early. We are in beta, not release ... the purpose of going to beta2 is to provide a new checkpoint to work bug reports off of, so having to deal with an initdb should not be considered a problem by anyone, since only a fool would run beta in production, no? (and ya, I am such a fool at times, but i do accept the fact that I am such *grin*) We should get _all_ the known initdb-related issues into the code before we go beta2 or beta3 is going to require another initdb. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] [HACKERS] PGXLOG variable worthwhile?
On Wed, 18 Sep 2002, Bruce Momjian wrote: Sorry, I don't see the logic here. Using postgresql.conf, you set it once and it remains set until you change it again. With -X, you have to use it every time. I think that's where the votes came from. Ah, so you are saying that you type out your full command line each and every time you start up the server? I know, in my case, I have a shell script setup that I edit my changes in so that I don't have to remember ... You argued that -X and GUC make sense, but why add -X when can get it done at once in postgresql.conf. Also, consider changing the location does require moving the WAL files, so you already have this extra step. Adding to postgresql.conf is easy. I don't think you can just point it at a random empty directory on startup. Our goal was to reduce params to postmaster/postgres in favor of GUC, not add to them. I don't disagree that editing postgresql.conf is easy, but its not something that ppl would naturally thing of ... if I want to move a directory with most servers I run, I will generally do a man to find out what command options are required to do this change, and, if none are provided, just create a god-forsaken symlink ... The man page for postmaster should have something in it like: -X directory Specifies an alternate location for WAL files. Superseded by setting xlog_path in postmaster.conf Hell, if you are going to remove -X because its 'easier to do it in postmaster.conf', you should be looking at removing *all* command line args that are better represented in the postmaster.conf file ... The only time that *I* use the postmaster.conf file is when I'm playing with the various scan'ng options ... why? mars# ps aux | grep -- B pgsql 133 0.0 0.0 77064 1512 con- SMon10PM 3:21.15 /usr/local/bin/postmaster -B 8192 -N 512 -o -S 4096 -i -p 5432 -D/v1/pgsql (postgres) pgsql 144 0.0 0.0 1097300 1372 ?? Is Mon10PM 0:06.04 /usr/local/pgsql/bin/postmaster -B 131072 -N 2048 -i -p 5433 -D/usr/local/pgsql/5433 -S (postgres) its nice to be able to do a simple ps to find out which process is which, and pointing where ... other then -D, I don't believe there is one option in there that I couldn't have set in the postmaster.conf file, but, then, to find out the various settings, I'd have to do ps to figure out where the database files are stored, and then go look at the postmaster.conf file to figure out what each are set to ... I have one server that has 10 instances running right now: jupiter# ps ax | grep -- -B 373 ?? Ss 0:55.31 /usr/local/pgsql721/bin/postmaster -B 10240 -N 512 -i -p 5432 -D/v1/pgsql/5432 -S (postgres) 383 ?? Ss 0:11.78 /usr/local/pgsql/bin/postmaster -B 64 -N 16 -i -p 5434 -D/v1/pgsql/5434 -S (postgres) 394 ?? Ss 0:17.82 /usr/local/pgsql/bin/postmaster -B 1024 -N 256 -i -p 5437 -D/v1/pgsql/5437 -S (postgres) 405 ?? Ss 0:16.46 /usr/local/pgsql/bin/postmaster -B 256 -N 128 -i -p 5440 -D/v1/pgsql/5440 -S (postgres) 416 ?? Ss 0:10.93 /usr/local/pgsql/bin/postmaster -B 256 -N 128 -i -p 5449 -D/v1/pgsql/5449 -S (postgres) 427 ?? Ss 0:16.30 /usr/local/pgsql/bin/postmaster -B 2048 -N 256 -i -p 5443 -D/v1/pgsql/5443 -S (postgres) 438 ?? Ss 0:10.60 /usr/local/pgsql721/bin/postmaster -B 1024 -N 512 -i -p 5446 -D/v1/pgsql/5446 -S (postgres) 88515 ?? Ss 0:10.05 /usr/local/pgsql/bin/postmaster -B 64 -N 16 -i -p 5433 -D/v1/pgsql/5433 -S (postgres) 13029 pi S+ 0:00.00 grep -- -B 445 con- S 0:10.59 /usr/local/pgsql/mb/bin/postmaster -B 256 -N 128 -i -p 5448 -D/v1/pgsql/openacs4 (postgres) 460 con- S 0:10.40 /usr/local/pgsql/bin/postmaster -B 64 -N 16 -i -p 5436 -D/v1/pgsql/electrichands (postgres) All the information for each are right there in front of me ... I don't have to go through 10 postmaster.conf files to figure out anything ... the GUC value should override the command line option, agreed ... but the ability to use the command line should not be removed just because some ppl aren't competent enough to adjust their startup scripts if they change their system ... ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
On Wed, 18 Sep 2002, Bruce Momjian wrote: Marc G. Fournier wrote: On Wed, 18 Sep 2002, Bruce Momjian wrote: We are going to require an initdb for beta2 and I think we need to get _everything_ required in there before going to beta2. See the open items list. I think we will need until the middle of next week for beta2. In fact, I have the inheritance patch that will require an initdb and that isn't even applied yet; Friday is too early. We are in beta, not release ... the purpose of going to beta2 is to provide a new checkpoint to work bug reports off of, so having to deal with an initdb should not be considered a problem by anyone, since only a fool would run beta in production, no? (and ya, I am such a fool at times, but i do accept the fact that I am such *grin*) We should get _all_ the known initdb-related issues into the code before we go beta2 or beta3 is going to require another initdb. Right, and? How many times in the past has it been the last beta in the cycle that forced the initdb? Are you able to guarantee that there *won't* be another initdb required if we wait until mid-next week? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: The TODO List (Was: Re: [HACKERS] Open 7.3 items)
On Wed, 18 Sep 2002, Bruce Momjian wrote: I think you are confusing the open items list with the TODO list. TODO usually has some basis, while open items is just that, things we need to decide on. Peter brought it up and wanted it on the list so I put it on. I can be taken off just as easily. I put Peter's name on the item, and a question mark. The open items list is just so we don't forget things. I'm in agreement with Thomas here ... unless a problem has been defined a bit more specifically then 'it isn't posix compliant', it shouldn't be considered an open item ... please remove? ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] [HACKERS] PGXLOG variable worthwhile?
Marc G. Fournier wrote: On Wed, 18 Sep 2002, Bruce Momjian wrote: Sorry, I don't see the logic here. Using postgresql.conf, you set it once and it remains set until you change it again. With -X, you have to use it every time. I think that's where the votes came from. Ah, so you are saying that you type out your full command line each and every time you start up the server? I know, in my case, I have a shell script setup that I edit my changes in so that I don't have to remember ... Yep, but your central place for changes should be postgresql.conf, not the command line. If we tried go get every GUC param on the command line it would be unusable. You argued that -X and GUC make sense, but why add -X when can get it done at once in postgresql.conf. Also, consider changing the location does require moving the WAL files, so you already have this extra step. Adding to postgresql.conf is easy. I don't think you can just point it at a random empty directory on startup. Our goal was to reduce params to postmaster/postgres in favor of GUC, not add to them. I don't disagree that editing postgresql.conf is easy, but its not something that ppl would naturally thing of ... if I want to move a directory with most servers I run, I will generally do a man to find out what command options are required to do this change, and, if none are provided, just create a god-forsaken symlink ... The man page for postmaster should have something in it like: -X directory Specifies an alternate location for WAL files. Superseded by setting xlog_path in postmaster.conf Hell, if you are going to remove -X because its 'easier to do it in postmaster.conf', you should be looking at removing *all* command line args that are better represented in the postmaster.conf file ... Well, those other options are things you may want to change frequently. The xlog directory isn't going to be moving around, we hope. We have the flags there only so they can be easily adjusted for testing, I think, and in fact there has been discussion about removing more of them. its nice to be able to do a simple ps to find out which process is which, and pointing where ... other then -D, I don't believe there is one option in there that I couldn't have set in the postmaster.conf file, but, then, to find out the various settings, I'd have to do ps to figure out where the database files are stored, and then go look at the postmaster.conf file to figure out what each are set to ... Yea, but you aren't going to be needing to know the xlog directory that way, will you? Fact is, xlog is seldom moved, and symlinks do it fine now. The GUC was a compromise for people who didn't like symlinks. If we are getting pushback from GUC we may as well just drop the GUC idea and stick with symlinks. I think that's how the vote went last time and it seems to be heading in that direction again. -- 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 4: Don't 'kill -9' the postmaster
Re: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
Marc G. Fournier wrote: On Wed, 18 Sep 2002, Bruce Momjian wrote: Marc G. Fournier wrote: On Wed, 18 Sep 2002, Bruce Momjian wrote: We are going to require an initdb for beta2 and I think we need to get _everything_ required in there before going to beta2. See the open items list. I think we will need until the middle of next week for beta2. In fact, I have the inheritance patch that will require an initdb and that isn't even applied yet; Friday is too early. We are in beta, not release ... the purpose of going to beta2 is to provide a new checkpoint to work bug reports off of, so having to deal with an initdb should not be considered a problem by anyone, since only a fool would run beta in production, no? (and ya, I am such a fool at times, but i do accept the fact that I am such *grin*) We should get _all_ the known initdb-related issues into the code before we go beta2 or beta3 is going to require another initdb. Right, and? How many times in the past has it been the last beta in the cycle that forced the initdb? Are you able to guarantee that there *won't* be another initdb required if we wait until mid-next week? I agree, but if we _know_ we have more initdb issues to resolve (and pg_dump load issues) doesn't it make sense to at least do all of them that we have outstanding? If not, we are guaranteeing an initdb. I would rather _try_ to avoid one for beta3. -- 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: The TODO List (Was: Re: [HACKERS] Open 7.3 items)
Marc G. Fournier wrote: On Wed, 18 Sep 2002, Bruce Momjian wrote: I think you are confusing the open items list with the TODO list. TODO usually has some basis, while open items is just that, things we need to decide on. Peter brought it up and wanted it on the list so I put it on. I can be taken off just as easily. I put Peter's name on the item, and a question mark. The open items list is just so we don't forget things. I'm in agreement with Thomas here ... unless a problem has been defined a bit more specifically then 'it isn't posix compliant', it shouldn't be considered an open item ... please remove? Removed. See, I can remove them as quickly as I add them. :-) -- 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 4: Don't 'kill -9' the postmaster
Re: The TODO List (Was: Re: [HACKERS] Open 7.3 items)
Marc G. Fournier [EMAIL PROTECTED] writes: I'm in agreement with Thomas here ... unless a problem has been defined a bit more specifically then 'it isn't posix compliant', it shouldn't be considered an open item ... please remove? A quick review of SQL99 says that their notion of SIMILAR TO patterns is an unholy witches' brew: it does *both* common-or-garden regexp expressions and LIKE patterns. Specifically, I see these metacharacters: | OR (regexp-ish) * repeat 0 or more times (regexp-ish) + repeat 1 or more times (regexp-ish) % match any character sequence (like LIKE) _ match any one character (like LIKE) [...] almost-but-not-quite-regexp-ish character class (...) grouping (regexp-ish) plus a just-like-LIKE treatment of a selectable escape character. But the most important variation from common regex practice is that (if I'm reading the spec correctly) the pattern must match to the entire target string --- ie, it's effectively both left- and right- anchored. This is like LIKE patterns but utterly unlike common regexp usage. I could live with the fact that our regexp patterns don't implement all of the spec-mandated metacharacters. But I do not think we can ignore the difference in anchoring behavior. This is not a subset of the spec behavior, it is just plain wrong. I vote with Peter: we fix this or we disable it before 7.3 release. It is not anywhere near spec compliant, and we will be doing no one a favor by releasing it in the current state. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] [HACKERS] PGXLOG variable worthwhile?
Marc G. Fournier [EMAIL PROTECTED] writes: On Wed, 18 Sep 2002, Bruce Momjian wrote: Sorry, I don't see the logic here. Using postgresql.conf, you set it once and it remains set until you change it again. With -X, you have to use it every time. I think that's where the votes came from. Ah, so you are saying that you type out your full command line each and every time you start up the server? Let's put it this way: would you be in favor of adding a --please-don't-wipe-my-database-directory switch to the postmaster? And if you forget to specify that every time you start the postmaster, we do an instant rm -rf $PGDATA? Doesn't seem like a good idea, does it? Well, specifying the XLOG location on the command line or as an environment variable is just about as deadly as the above loaded-gun- pointed-at-foot scenario. You start the postmaster with the wrong context, even once, it's sayonara to your data integrity. The point of insisting that the XLOG location be recorded *inside* the data directory is to prevent simple admin errors from being catastrophic. Do you remember when we regularly saw trouble reports from people who'd corrupted their database indexes by starting the postmaster with different LOCALE environments at different times? We fixed that by forcing the locale collation order to be specified inside the database directory (in pg_control, but the details are not important here), rather than allowing it to be taken from postmaster environment. If we allow XLOG location to be determined by a postmaster switch or environment variable, then we *will* be opening the door for people to shoot themselves in the foot just like they used to do with locale. I learned something from those problems, and I do not intend to make the same mistake again. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
Marc G. Fournier [EMAIL PROTECTED] writes: On Wed, 18 Sep 2002, Bruce Momjian wrote: We should get _all_ the known initdb-related issues into the code before we go beta2 or beta3 is going to require another initdb. Right, and? How many times in the past has it been the last beta in the cycle that forced the initdb? Are you able to guarantee that there won't* be another initdb required if we wait until mid-next week? I completely agree with Bruce here. Requiring an initdb for every beta release significantly reduces the number of people who will be willing to try it out -- so initdb's between betas are not disasterous, but should be avoided if possible. Since waiting till next week significantly reduces the chance of an initdb for beta3 and has no serious disadvantage that I can see, it seems the right decision to me. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
I completely agree with Bruce here. Requiring an initdb for every beta release significantly reduces the number of people who will be willing to try it out -- so initdb's between betas are not disasterous, but should be avoided if possible. But it does mean that 7.3 to 7.3 pg_dump gets a good testing... You could almost make it mandatory to have an initdb during beta :) 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: The TODO List (Was: Re: [HACKERS] Open 7.3 items)
Re-added to open items: Fix SIMILAR TO to be ANSI compliant or remove it (Peter, Tom) --- Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: I'm in agreement with Thomas here ... unless a problem has been defined a bit more specifically then 'it isn't posix compliant', it shouldn't be considered an open item ... please remove? A quick review of SQL99 says that their notion of SIMILAR TO patterns is an unholy witches' brew: it does *both* common-or-garden regexp expressions and LIKE patterns. Specifically, I see these metacharacters: | OR (regexp-ish) * repeat 0 or more times (regexp-ish) + repeat 1 or more times (regexp-ish) % match any character sequence (like LIKE) _ match any one character (like LIKE) [...] almost-but-not-quite-regexp-ish character class (...) grouping (regexp-ish) plus a just-like-LIKE treatment of a selectable escape character. But the most important variation from common regex practice is that (if I'm reading the spec correctly) the pattern must match to the entire target string --- ie, it's effectively both left- and right- anchored. This is like LIKE patterns but utterly unlike common regexp usage. I could live with the fact that our regexp patterns don't implement all of the spec-mandated metacharacters. But I do not think we can ignore the difference in anchoring behavior. This is not a subset of the spec behavior, it is just plain wrong. I vote with Peter: we fix this or we disable it before 7.3 release. It is not anywhere near spec compliant, and we will be doing no one a favor by releasing it in the current state. regards, tom lane ---(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 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: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
Marc G. Fournier [EMAIL PROTECTED] writes: ... I'm going to do up a beta2 on Friday due to the number changes that have been committed over the past 2 weeks ... I want to review and apply Alvaro's attisinherited fix before we go beta2. I think I can get that done tomorrow. I can't recall any other initdb-forcing fixes in the pipeline; Bruce, do you? Which is not to say we don't have a ton of known bugs to fix... I'd lean towards a Monday-ish beta2 myself. 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: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: ... I'm going to do up a beta2 on Friday due to the number changes that have been committed over the past 2 weeks ... I want to review and apply Alvaro's attisinherited fix before we go beta2. I think I can get that done tomorrow. I can't recall any other initdb-forcing fixes in the pipeline; Bruce, do you? Looking at the open item list, I see: fix up function return types on lang/type/trigger creation or loosen opaque restrictions Seems that should be fixed before beta2 because it does effect people loading data. Are we done with all of these? Add casts: (Tom) assignment-level cast specification inet - text macaddr - text int4 - varchar? int8 - varchar? add param for length check for char()/varchar() Which is not to say we don't have a ton of known bugs to fix... I'd lean towards a Monday-ish beta2 myself. Yes, I would like to get a few days of quiet before packaging beta2. -- 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] GRANT EXECUTE
Hi, Should someone just go though contrib/ and add GRANT EXECUTE on everything? Seems pointless doing it ad hoc by the maintainer as it is at the moment...? Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Beta2 on Friday Morning (Was: Re: [HACKERS] Open 7.3 items)
On Wed, 18 Sep 2002, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: ... I'm going to do up a beta2 on Friday due to the number changes that have been committed over the past 2 weeks ... I want to review and apply Alvaro's attisinherited fix before we go beta2. I think I can get that done tomorrow. I can't recall any other initdb-forcing fixes in the pipeline; Bruce, do you? Which is not to say we don't have a ton of known bugs to fix... I'd lean towards a Monday-ish beta2 myself. 'k, then let's go with a Sunday night packaging, Monday announce, so that we have beta2 testing starting right at the beginning of the week ... ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: The TODO List (Was: Re: [HACKERS] Open 7.3 items)
On Wed, 18 Sep 2002, Bruce Momjian wrote: Re-added to open items: Fix SIMILAR TO to be ANSI compliant or remove it (Peter, Tom) Tke that @#$@$@@$@#$ thing out of there until its actually been fully discussed ... you are starting to remind me of Charlie Brown ... this, I think, was Thomas' whole point, in that things are added way too faster and easily without fully understanding all of the ramifications ... let a discussion cool down *before* you take things off, or add things to, the list ... --- Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: I'm in agreement with Thomas here ... unless a problem has been defined a bit more specifically then 'it isn't posix compliant', it shouldn't be considered an open item ... please remove? A quick review of SQL99 says that their notion of SIMILAR TO patterns is an unholy witches' brew: it does *both* common-or-garden regexp expressions and LIKE patterns. Specifically, I see these metacharacters: | OR (regexp-ish) * repeat 0 or more times (regexp-ish) + repeat 1 or more times (regexp-ish) % match any character sequence (like LIKE) _ match any one character (like LIKE) [...] almost-but-not-quite-regexp-ish character class (...) grouping (regexp-ish) plus a just-like-LIKE treatment of a selectable escape character. But the most important variation from common regex practice is that (if I'm reading the spec correctly) the pattern must match to the entire target string --- ie, it's effectively both left- and right- anchored. This is like LIKE patterns but utterly unlike common regexp usage. I could live with the fact that our regexp patterns don't implement all of the spec-mandated metacharacters. But I do not think we can ignore the difference in anchoring behavior. This is not a subset of the spec behavior, it is just plain wrong. I vote with Peter: we fix this or we disable it before 7.3 release. It is not anywhere near spec compliant, and we will be doing no one a favor by releasing it in the current state. regards, tom lane ---(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 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: The TODO List (Was: Re: [HACKERS] Open 7.3 items)
It is an open issue. It has to be resolved. When it is, I will remove it. I added a question mark to it but it needs to be tracked. I keep having to add and remove it because I have people telling me what to do. It was Peter who told me to add it, and you and Thomas to remove it. It isn't me adding/removing on my own. --- Marc G. Fournier wrote: On Wed, 18 Sep 2002, Bruce Momjian wrote: Re-added to open items: Fix SIMILAR TO to be ANSI compliant or remove it (Peter, Tom) Tke that @#$@$@@$@#$ thing out of there until its actually been fully discussed ... you are starting to remind me of Charlie Brown ... this, I think, was Thomas' whole point, in that things are added way too faster and easily without fully understanding all of the ramifications ... let a discussion cool down *before* you take things off, or add things to, the list ... --- Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: I'm in agreement with Thomas here ... unless a problem has been defined a bit more specifically then 'it isn't posix compliant', it shouldn't be considered an open item ... please remove? A quick review of SQL99 says that their notion of SIMILAR TO patterns is an unholy witches' brew: it does *both* common-or-garden regexp expressions and LIKE patterns. Specifically, I see these metacharacters: | OR (regexp-ish) * repeat 0 or more times (regexp-ish) + repeat 1 or more times (regexp-ish) % match any character sequence (like LIKE) _ match any one character (like LIKE) [...] almost-but-not-quite-regexp-ish character class (...) grouping (regexp-ish) plus a just-like-LIKE treatment of a selectable escape character. But the most important variation from common regex practice is that (if I'm reading the spec correctly) the pattern must match to the entire target string --- ie, it's effectively both left- and right- anchored. This is like LIKE patterns but utterly unlike common regexp usage. I could live with the fact that our regexp patterns don't implement all of the spec-mandated metacharacters. But I do not think we can ignore the difference in anchoring behavior. This is not a subset of the spec behavior, it is just plain wrong. I vote with Peter: we fix this or we disable it before 7.3 release. It is not anywhere near spec compliant, and we will be doing no one a favor by releasing it in the current state. regards, tom lane ---(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 -- 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])
Re: [GENERAL] [HACKERS] PGXLOG variable worthwhile?
On Wed, 18 Sep 2002, Bruce Momjian wrote: Yea, but you aren't going to be needing to know the xlog directory that way, will you? Why not? Who are you to tell me how my scripts work, or how they get their information? I have a script that runs to tell me how much disk space each instance is using up, that parses the ps output for the -D argument ... having -X there would allow me to parse for that as well and, if it was in the ps output, add that appropriately into the calculations ... My point is, the functionality is there, and should be documented properly ... encourage ppl to use the GUC setting in postmaster.conf, but just because you can't grasp that some of us *like* to use command line args, don't remove such functionality ... ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] [HACKERS] PGXLOG variable worthwhile?
Marc G. Fournier wrote: On Wed, 18 Sep 2002, Bruce Momjian wrote: Yea, but you aren't going to be needing to know the xlog directory that way, will you? Why not? Who are you to tell me how my scripts work, or how they get their information? I have a script that runs to tell me how much disk space each instance is using up, that parses the ps output for the -D argument ... having -X there would allow me to parse for that as well and, if it was in the ps output, add that appropriately into the calculations ... My point is, the functionality is there, and should be documented properly ... encourage ppl to use the GUC setting in postmaster.conf, but just because you can't grasp that some of us *like* to use command line args, don't remove such functionality ... You ask for a vote and see if you can get votes to add -X. We had that vote once already. We do make decisions on what people should use. If not, we would be as hard to manage as Oracle. -- 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 4: Don't 'kill -9' the postmaster
Re: [GENERAL] [HACKERS] PGXLOG variable worthwhile?
On Wed, 18 Sep 2002, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: On Wed, 18 Sep 2002, Bruce Momjian wrote: Sorry, I don't see the logic here. Using postgresql.conf, you set it once and it remains set until you change it again. With -X, you have to use it every time. I think that's where the votes came from. Ah, so you are saying that you type out your full command line each and every time you start up the server? Let's put it this way: would you be in favor of adding a --please-don't-wipe-my-database-directory switch to the postmaster? And if you forget to specify that every time you start the postmaster, we do an instant rm -rf $PGDATA? Doesn't seem like a good idea, does it? Well, specifying the XLOG location on the command line or as an environment variable is just about as deadly as the above loaded-gun- pointed-at-foot scenario. You start the postmaster with the wrong context, even once, it's sayonara to your data integrity. The point of insisting that the XLOG location be recorded *inside* the data directory is to prevent simple admin errors from being catastrophic. Do you remember when we regularly saw trouble reports from people who'd corrupted their database indexes by starting the postmaster with different LOCALE environments at different times? We fixed that by forcing the locale collation order to be specified inside the database directory (in pg_control, but the details are not important here), rather than allowing it to be taken from postmaster environment. If we allow XLOG location to be determined by a postmaster switch or environment variable, then we *will* be opening the door for people to shoot themselves in the foot just like they used to do with locale. I learned something from those problems, and I do not intend to make the same mistake again. Except that you are ... you are assuming that someone is going to edit their postmaster.conf file correctly ... if you want to avoid making the same mistake again, there should be some sort of 'tag' that associates the files in the XLOG directory with the data directories themselves, regardless of *how* the XLOG directory is referenced ... something that links them at a level that an administrator *can't* make a mistake about ... all forcing the use of the postmaster.conf file is doing is reducing options, it isn't making sure that the XLOG directory pointed to is apporopraite for the data directory itself ... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: The TODO List (Was: Re: [HACKERS] Open 7.3 items)
On Thu, 19 Sep 2002, Bruce Momjian wrote: It is an open issue. It has to be resolved. When it is, I will remove it. I added a question mark to it but it needs to be tracked. I keep having to add and remove it because I have people telling me what to do. It was Peter who told me to add it, and you and Thomas to remove it. It isn't me adding/removing on my own. Right, so you have two telling you to remove it, one telling you to add it, and two that are discussion why/if it *should* be added ... Tom feels it should be added, and I'm clarifing the why of it ... don't re-add it until we've determined *if* it is actually an open issue or not ... stop jumping the gun ... --- Marc G. Fournier wrote: On Wed, 18 Sep 2002, Bruce Momjian wrote: Re-added to open items: Fix SIMILAR TO to be ANSI compliant or remove it (Peter, Tom) Tke that @#$@$@@$@#$ thing out of there until its actually been fully discussed ... you are starting to remind me of Charlie Brown ... this, I think, was Thomas' whole point, in that things are added way too faster and easily without fully understanding all of the ramifications ... let a discussion cool down *before* you take things off, or add things to, the list ... --- Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: I'm in agreement with Thomas here ... unless a problem has been defined a bit more specifically then 'it isn't posix compliant', it shouldn't be considered an open item ... please remove? A quick review of SQL99 says that their notion of SIMILAR TO patterns is an unholy witches' brew: it does *both* common-or-garden regexp expressions and LIKE patterns. Specifically, I see these metacharacters: | OR (regexp-ish) * repeat 0 or more times (regexp-ish) + repeat 1 or more times (regexp-ish) % match any character sequence (like LIKE) _ match any one character (like LIKE) [...] almost-but-not-quite-regexp-ish character class (...) grouping (regexp-ish) plus a just-like-LIKE treatment of a selectable escape character. But the most important variation from common regex practice is that (if I'm reading the spec correctly) the pattern must match to the entire target string --- ie, it's effectively both left- and right- anchored. This is like LIKE patterns but utterly unlike common regexp usage. I could live with the fact that our regexp patterns don't implement all of the spec-mandated metacharacters. But I do not think we can ignore the difference in anchoring behavior. This is not a subset of the spec behavior, it is just plain wrong. I vote with Peter: we fix this or we disable it before 7.3 release. It is not anywhere near spec compliant, and we will be doing no one a favor by releasing it in the current state. regards, tom lane ---(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 -- 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: The TODO List (Was: Re: [HACKERS] Open 7.3 items)
Marc G. Fournier wrote: On Thu, 19 Sep 2002, Bruce Momjian wrote: It is an open issue. It has to be resolved. When it is, I will remove it. I added a question mark to it but it needs to be tracked. I keep having to add and remove it because I have people telling me what to do. It was Peter who told me to add it, and you and Thomas to remove it. It isn't me adding/removing on my own. Right, so you have two telling you to remove it, one telling you to add it, and two that are discussion why/if it *should* be added ... Tom feels it should be added, and I'm clarifing the why of it ... don't re-add it until we've determined *if* it is actually an open issue or not ... stop jumping the gun ... I will make the decision. If you want to maintain your own open items list, go ahead. -- 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] Win32 rename()/unlink() questions
On Wed, Sep 18, 2002 at 08:01:42PM -0400, Bruce Momjian wrote: Second, when you unlink() a file on Win32, do applications continue accessing the old file contents if they had the file open before the unlink? I'm pretty sure it errors with 'file in use'. Pretty ugly, huh? Ross ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Win32 rename()/unlink() questions
On Wed, Sep 18, 2002 at 08:01:42PM -0400, Bruce Momjian wrote: Second, when you unlink() a file on Win32, do applications continue accessing the old file contents if they had the file open before the unlink? I'm pretty sure it errors with 'file in use'. Pretty ugly, huh? Yeah - the windows filesystem is pretty poor when it comes to multiuser access. That's why even as administrator I cannot delete borked files and people's profiles and stuff off our NT server - the files are always 'in use'. Even if you kick all users off, reboot the machine, do whatever. It's terrible. Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Win32 rename()/unlink() questions
Bruce Momjian wrote: I am working with several groups getting the Win32 port ready for 7.4 and I have a few questions: What is the standard workaround for the fact that rename() isn't atomic on Win32? Do we need to create our own locking around the reading/writing of files that are normally updated in place using rename()? Visual C++ comes with the source to Microsoft's C library: rename() calls MoveFile() which will error if: 1. The target file exists 2. The source file is in use MoveFileEx() (not available on 95/98) can overwrite the target file if it exists. The Apache APR portability library uses MoveFileEx() to rename files if under NT/XP/2K vs. a sequence of : 1. CreateFile() to test for target file existence 2. DeleteFile() to remove the target file 3. MoveFile() to rename the old file to new under Windows 95/98. Of course, some other process could create the target file between 2 and 3, so their rename() would just error out in that situation. I haven't tested it, but I recall reading somewhere that MoveFileEx() has the ability to rename an opened file. I'm 99% sure MoveFile() will fail if the source file is open. Second, when you unlink() a file on Win32, do applications continue accessing the old file contents if they had the file open before the unlink? unlink() just calls DeleteFile() which will error if: 1. The target file is in use CreateFile() has the option: FILE_FLAG_DELETE_ON_CLOSE which might be able to be used to simulate traditional unlink() behavior. Hope that helps, Mike Mascari [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Win32 rename()/unlink() questions
Christopher Kings-Lynne wrote: On Wed, Sep 18, 2002 at 08:01:42PM -0400, Bruce Momjian wrote: Second, when you unlink() a file on Win32, do applications continue accessing the old file contents if they had the file open before the unlink? I'm pretty sure it errors with 'file in use'. Pretty ugly, huh? Yeah - the windows filesystem is pretty poor when it comes to multiuser access. That's why even as administrator I cannot delete borked files and people's profiles and stuff off our NT server - the files are always 'in use'. Even if you kick all users off, reboot the machine, do whatever. It's terrible. Chris Yep. That's why often it requires rebooting to uninstall software. How can the installer remove itself? Under Windows 95/98/ME, you have to manually add entries to WININIT.INI. With Windows NT/XP/2K, MoveFileEx() with a NULL target and the MOVEFILE_DELAY_UNTIL_REBOOT flag will add the appropriate entries into the system registry so that the next time the machine reboots it will remove the files specified. Its a real pain and a real hack of an OS. Mike Mascari [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Inconsistent Conversion Names
I thought you had named the conversion functions after the IANA names. I found the following inconsistencies, however: sjis should be shift_jis The conversion named SJIS is different from IANA's shift_jis. It actually matches Windows-31J in IANA, which is too ugly to being emploied as our conversion name, IMO. win1250 should be windows_1250 (similarly 866, 1251) I agree with win1250 - windows_1250, win1251 - windows_1251, but do not agree with renaming win866. There's no windows_866 in IANA. Maybe that should be ibm866? koi8r should be koi8_r Someone said that the conversion table is actually koi8r + koi8u, being different from IANA's koi8_r. Not sure though. -- Tatsuo Ishii ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
