[HACKERS] psql i18n - sk
Dear hackers, attached you may find the slovak (sk) translation of the psql message strings. I wanted to check out the newest ones (my version is from jul.16) but I was told by my browser that no such file existed (http://developer.postgresql.org/~petere/nlsstatus/po-current/psql.pot), so maybe I just missed something. Please have a look at it. In the next few days I would like to commit a few other i18n-sk files too. Greetings Zoltan psql-sk.po.bz2 Description: BZip2 compressed data ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] psql i18n - sk
Zoltan Bartko wrote: attached you may find the slovak (sk) translation of the psql message strings. Installed. I wanted to check out the newest ones (my version is from jul.16) but I was told by my browser that no such file existed (http://developer.postgresql.org/~petere/nlsstatus/po-current/psql.po t), so maybe I just missed something. It's currently broken because of some earlier breakage in a translation, but it should be back in a few hours. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Compile failure on nl_langinfo
Hi, I am seeing the following compile failure in currrent CVS. gmake[4]: Leaving directory `/dados/pgsql/cvs/pgsql/src/port' gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -DFRONTEND -I../../../src/interfaces/libpq -I../../../src/include -I/usr/local/include -I/usr/local/include/tcl8.4 -c -o initdb.o initdb.c -MMD initdb.c: In function `get_encoding_from_locale': initdb.c:758: `CODESET' undeclared (first use in this function) initdb.c:758: (Each undeclared identifier is reported only once initdb.c:758: for each function it appears in.) gmake[3]: *** [initdb.o] Error 1 gmake[3]: Leaving directory `/dados/pgsql/cvs/pgsql/src/bin/initdb' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/dados/pgsql/cvs/pgsql/src/bin' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/dados/pgsql/cvs/pgsql/src' gmake: *** [all] Error 2 $ I am using an OpenBSD 3.5. OpenBSD doesn't have 'CODESET' symbol. How can we fix it? 1) just define it on configure.in when we don't have it. Like this: dnl Check for nl_langinfo and CODESET AC_MSG_CHECKING([for nl_langinfo (CODESET)]) AC_TRY_LINK([#include langinfo.h], [char *codeset = nl_langinfo (CODESET);], [AC_MSG_RESULT(yes)], [AC_MSG_RESULT(no) AC_DEFINE(CODESET, 0, [Define to 0 if you don't have CODESET.]) ]) 2) define a 'HAVE_CODESET' symbol and just ifdef in initdb.c 3) another? Personally I prefer the first one. The completed patch is attached. It requires to run 'autoheader' and 'autoconf'. CODESET 0 is ASCII. So in those plataforms that do not have 'CODESET' we'll always go with locale C. Comments? -- Euler Taveira de Oliveira euler (at) ufgnet.ufg.br Desenvolvedor Web e Administrador de Sistemas UFGNet - Universidade Federal de Goiás foo.diff Description: Binary data ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Compile failure on nl_langinfo
Euler Taveira de Oliveira wrote: I am using an OpenBSD 3.5. OpenBSD doesn't have 'CODESET' symbol. How can we fix it? Put #ifdef CODESET around the offending code. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Compile failure on nl_langinfo
Euler Taveira de Oliveira [EMAIL PROTECTED] writes: I am using an OpenBSD 3.5. OpenBSD doesn't have 'CODESET' symbol. How can we fix it? 1) just define it on configure.in when we don't have it. Like this: You've got to be kidding. That will cause get_encoding_from_locale to return some random bit of information (whatever is mapped to zero), with who-knows-what result. A configure-time probe seems unnecessary anyway, since we can just do #ifdef CODESET in initdb.c. The real question is what we should do if it isn't defined. We can certainly make get_encoding_from_locale return NULL, but it looks like initdb will behave moderately unpleasantly if we do that (ie, force you to specify -E in most cases). Is there any reasonable fallback behavior? 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
[HACKERS] Trapping QUERY_CANCELED: yes, no, maybe?
Now that it is possible for plpgsql functions (and, no doubt, soon others) to trap errors, I think we need a little bit of discussion about what kind of restrictions should be put on trapping the QUERY_CANCELED error. If we treat QUERY_CANCELED as an absolutely ordinary error, it would be fairly easy for a carelessly written function to disable the backend from responding to ^C or statement_timeout --- it need only catch the error and keep on processing. On the other hand, it's not impossible to envision scenarios where you'd like to be able to catch QUERY_CANCELED. I can see people using that ability in combination with statement_timeout, in particular. The compromise that I put into plpgsql for the moment works like this: 1. EXCEPTION WHEN OTHERS THEN matches all error types *except* QUERY_CANCELED; thus you cannot accidentally catch that error. (When the EXCEPTION clause does not match the error type, the error just propagates outward, so QUERY_CANCELED will always force control back to the idle loop.) 2. But you can explicitly say EXCEPTION WHEN QUERY_CANCELED THEN if you really want to catch it. I can see that point #2 might be controversial, and that some might feel that QUERY_CANCELED should be untrappable, period. Does anyone want to argue for that? Does anyone think #1 is a bad idea? There is also an implementation-level issue, which is whether we should rely on the PLs' individual error handlers (which are mostly yet to be written) to enforce such policies consistently. As long as QUERY_CANCELED is the only special case, things aren't too bad, but if there's any prospect of having more special cases it could get messy. I thought about inventing a new elevel category, but really that does not help much, since we'd still be dependent on the error handlers to be cooperative. (We can't not run the handlers, since there is very likely state that they *must* undo before losing control.) Anyone see a cleaner approach? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Compile failure on nl_langinfo
Tom Lane wrote: Euler Taveira de Oliveira [EMAIL PROTECTED] writes: I am using an OpenBSD 3.5. OpenBSD doesn't have 'CODESET' symbol. How can we fix it? 1) just define it on configure.in when we don't have it. Like this: You've got to be kidding. That will cause get_encoding_from_locale to return some random bit of information (whatever is mapped to zero), with who-knows-what result. A configure-time probe seems unnecessary anyway, since we can just do #ifdef CODESET in initdb.c. The real question is what we should do if it isn't defined. We can certainly make get_encoding_from_locale return NULL, but it looks like initdb will behave moderately unpleasantly if we do that (ie, force you to specify -E in most cases). Is there any reasonable fallback behavior? A quick Google shows Mozilla falling back to ISO-8859-1 cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Compile failure on nl_langinfo
Hi Peter, I am using an OpenBSD 3.5. OpenBSD doesn't have 'CODESET' symbol. How can we fix it? Put #ifdef CODESET around the offending code. OK. Another try. -- Euler Taveira de Oliveira euler (at) ufgnet.ufg.br Desenvolvedor Web e Administrador de Sistemas UFGNet - Universidade Federal de Goiás initdb.diff Description: Binary data ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Anybody have an Oracle PL/SQL reference at hand?
Can anyone check how well the syntax of plpgsql EXCEPTION, as described at http://developer.postgresql.org/docs/postgres/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING agrees with what Oracle does? I did some googling but couldn't find anything that seemed authoritative. I'm wondering in particular if Oracle allows multiple condition names per WHEN, along the lines of WHEN condition [ , condition ... ] THEN handler_statements Also it would be nice to see a complete list of the condition names that they accept. I whipped up a quick table based on our ERRCODE macro names, see http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/pl/plpgsql/src/plerrcodes.h but I'm certain that's not what we really want to expose to users in the long run. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Compile failure on nl_langinfo
Euler Taveira de Oliveira wrote: I am using an OpenBSD 3.5. OpenBSD doesn't have 'CODESET' symbol. How can we fix it? Put #ifdef CODESET around the offending code. OK. Another try. What does nl_langinfo(NULL) return? Probably not a valid codepage. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] Anybody have an Oracle PL/SQL reference at hand?
Tom Lane wrote: Can anyone check how well the syntax of plpgsql EXCEPTION, as described at http://developer.postgresql.org/docs/postgres/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING agrees with what Oracle does? I did some googling but couldn't find anything that seemed authoritative. I'm wondering in particular if Oracle allows multiple condition names per WHEN, along the lines of WHEN condition [ , condition ... ] THEN handler_statements Also it would be nice to see a complete list of the condition names that they accept. I whipped up a quick table based on our ERRCODE macro names, see http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/pl/plpgsql/src/plerrcodes.h but I'm certain that's not what we really want to expose to users in the long run. It appears you can have multiple exceptions in a single handler, but that the separator is 'OR' rather than ','. See http://www.cise.ufl.edu/help/database/oracle-docs/appdev.920/a96624/13_elems17.htm The page also gives a link to a list of the predefined exceptions. PL/SQL allows users to define and raise their own exceptions too. cheers andrew ---(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] Anybody have an Oracle PL/SQL reference at hand?
Hello, From I can tell from Oracle pl/SQL programming page 130 ;) it is identical. However Oracle does have thinkgs like EXCEPTION_INIT. Here are the name of the Oracle predefined exceptions: CURSOR_ALREADY_OPEN DUP_VAL_ON_INDEX INVALID_CURSOR INVALID_NUMBER LOGIN_DENIED NO_DATA_FOUND NOT_LOGGED_IN PROGRAM_ERROR STORAGE_ERROR TIMEOUT_ON_RESOURCE TOO_MANY_ROWS TRANSACTION_BACKED_OUT VALUE_ERROR Sincerely, Joshua D. Drake Tom Lane wrote: Can anyone check how well the syntax of plpgsql EXCEPTION, as described at http://developer.postgresql.org/docs/postgres/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING agrees with what Oracle does? I did some googling but couldn't find anything that seemed authoritative. I'm wondering in particular if Oracle allows multiple condition names per WHEN, along the lines of WHEN condition [ , condition ... ] THEN handler_statements Also it would be nice to see a complete list of the condition names that they accept. I whipped up a quick table based on our ERRCODE macro names, see http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/pl/plpgsql/src/plerrcodes.h but I'm certain that's not what we really want to expose to users in the long run. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL begin:vcard fn:Joshua D. Drake n:Drake;Joshua D. org:Command Prompt, Inc. adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0034 note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl. x-mozilla-html:FALSE url:http://www.commandprompt.com/ version:2.1 end:vcard ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Compile failure on nl_langinfo
Hi Peter, I am using an OpenBSD 3.5. OpenBSD doesn't have 'CODESET' symbol. How can we fix it? Put #ifdef CODESET around the offending code. OK. Another try. What does nl_langinfo(NULL) return? Probably not a valid codepage. No. Just . See http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/locale/nl_langinfo.c?rev=1.3content-type=text/x-cvsweb-markup Isn't it acceptable? I just got locale C at initdb. But I saw this we I try to set an specific locale: $ initdb --locale=pt_BR initdb: invalid locale name pt_BR initdb: invalid locale name pt_BR initdb: invalid locale name pt_BR initdb: invalid locale name pt_BR initdb: invalid locale name pt_BR initdb: invalid locale name pt_BR The files belonging to this database system will be owned by user euler. This user must also own the server process. The database cluster will be initialized with locale C. The chklocale() seems to fail. I don't set neither LC_* nor LANG. -- Euler Taveira de Oliveira euler (at) ufgnet.ufg.br Desenvolvedor Web e Administrador de Sistemas UFGNet - Universidade Federal de Goiás ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] plpgsql compile error on win32
With the latest commits, plpgsql no longer compiles on win32, because of a link failure to pg_strcasecmp(). I fixed this locally by adding -lpgport to SHLIB_LINK in the makefile in pl/plpgsql/src, but I'm not sure if that is the correct long-term fix? //Magnus ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Anybody have an Oracle PL/SQL reference at hand?
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: Can anyone check how well the syntax of plpgsql EXCEPTION, as described at http://developer.postgresql.org/docs/postgres/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING agrees with what Oracle does? It appears you can have multiple exceptions in a single handler, but that the separator is 'OR' rather than ','. See http://www.cise.ufl.edu/help/database/oracle-docs/appdev.920/a96624/13_elems17.htm Got it. We can do that. The page also gives a link to a list of the predefined exceptions. Hmm. Not only is that a pretty short list, but many of them don't correspond very closely to the errors that Postgres would raise. Maybe we should just forget about trying to be compatible with Oracle's condition names. That still leaves us with needing to decide what our condition names should be, though. One thing that just occurred to me is that we should accept the category names (in errcodes.h, the exceptions with '000' as the last three digits of the code) as matching any exception in their category. PL/SQL allows users to define and raise their own exceptions too. Yeah. Our RAISE statement really needs a lot of work, but I think it will have to be left for a future release cycle ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] plpgsql compile error on win32
Magnus Hagander [EMAIL PROTECTED] writes: With the latest commits, plpgsql no longer compiles on win32, because of a link failure to pg_strcasecmp(). That doesn't make any sense. It should resolve it as a function in the backend. Why isn't that happening? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Another PITR question
Hi all, I have another PITR question on my mind: As I see it, PITR has 2 functions: 1 is to recover a disaster like a disk crash. Change the disk, restore PGDATA and play the logs back that'fine. 2 Junior DBA (or customer) says ch..; I droped the wrong table... In that case, restoring PGDATA restores the whole cluster. Is there a way just to restore $PGDATA/base/datoid? Or did I miss something. I'm testing 7.5dev on unixware and I'm impressed by how fast it gets. Although creating integer indexes *SEEMS* a bit slow but it's out of topic. Thanks for the great work! -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] plpgsql compile error on win32
With the latest commits, plpgsql no longer compiles on win32, because of a link failure to pg_strcasecmp(). That doesn't make any sense. It should resolve it as a function in the backend. Why isn't that happening? Dunno... Build output without my fix is: dlltool --export-all --output-def plpgsql.def pl_gram.o pl_handler.o pl_comp.o pl_exec.o pl_funcs.o dllwrap -o libplpgsql.dll --dllname libplpgsql.dll --def plpgsql.def pl_gram.o pl_handler.o pl_comp.o pl_exec.o pl_funcs.o -L../../../../src/port -L../../../../src/backend -lpostgres pl_exec.o(.text+0x2c33):pl_exec.c: undefined reference to `pg_strcasecmp' pl_exec.o(.text+0x2c78):pl_exec.c: undefined reference to `pg_strcasecmp' d:\mingw\bin\dllwrap.exe: d:\mingw\bin\gcc exited with status 1 make: *** [libplpgsql.a] Error 1 pg_strcasecmp is *not* included in libpostgres.a. It is in port/libpgport.a, though. (It's also in postgres.exe, but we don't link against that..) //Magnus ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Anybody have an Oracle PL/SQL reference at hand?
Hi Tom, I have sent you and the list the HTML page from the oracle tech network describing all of this. However, it seems to have disappeared in to the void since you don't seem to have received it and it hasn't hit the list yet. You can get a free login to access all the oracle docs and manuals, here: http://otn.oracle.com/pls/db10g/portal.portal_demo3?selected=1 If you like, however, I can just zip and email you the full PL/SQL PDF manual that I just downloaded from the above URL. Let me know if you want the PDF emailed to you. Can anyone check how well the syntax of plpgsql EXCEPTION, as described at http://developer.postgresql.org/docs/postgres/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING agrees with what Oracle does? I did some googling but couldn't find anything that seemed authoritative. I'm wondering in particular if Oracle allows multiple condition names per WHEN, along the lines of WHEN condition [ , condition ... ] THEN handler_statements It does, but with a different syntax: --- If you want two or more exceptions to execute the same sequence of statements, list the exception names in the WHEN clause, separating them by the keyword OR, as follows: EXCEPTION WHEN over_limit OR under_limit OR VALUE_ERROR THEN -- handle the error If any of the exceptions in the list is raised, the associated sequence of statements is executed. The keyword OTHERS cannot appear in the list of exception names; it must appear by itself. You can have any number of exception handlers, and each handler can associate a list of exceptions with a sequence of statements. However, an exception name can appear only once in the exception-handling part of a PL/SQL block or subprogram. --- Also it would be nice to see a complete list of the condition names that they accept. I whipped up a quick table based on our ERRCODE macro names, see http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/pl/plpgsql/src/plerrcodes.h but I'm certain that's not what we really want to expose to users in the long run. -- ACCESS_INTO_NULL A program attempts to assign values to the attributes of an uninitialized object. CASE_NOT_FOUND None of the choices in the WHEN clauses of a CASE statement is selected, and there is no ELSE clause. COLLECTION_IS_NULL A program attempts to apply collection methods other than EXISTS to an uninitialized nested table or varray, or the program attempts to assign values to the elements of an uninitialized nested table or varray. CURSOR_ALREADY_OPEN A program attempts to open an already open cursor. A cursor must be closed before it can be reopened. A cursor FOR loop automatically opens the cursor to which it refers, so your program cannot open that cursor inside the loop. DUP_VAL_ON_INDEX A program attempts to store duplicate values in a database column that is constrained by a unique index. INVALID_CURSOR A program attempts a cursor operation that is not allowed, such as closing an unopened cursor. INVALID_NUMBER In a SQL statement, the conversion of a character string into a number fails because the string does not represent a valid number. (In procedural statements, VALUE_ERROR is raised.) This exception is also raised when the LIMIT-clause expression in a bulk FETCH statement does not evaluate to a positive number. LOGIN_DENIED A program attempts to log on to Oracle with an invalid username or password. NO_DATA_FOUND A SELECT INTO statement returns no rows, or your program references a deleted element in a nested table or an uninitialized element in an index-by table. Because this exception is used internally by some SQL functions to signal that they are finished, you should not rely on this exception being propagated if you raise it within a function that is called as part of a query. NOT_LOGGED_ON A program issues a database call without being connected to Oracle. PROGRAM_ERROR PL/SQL has an internal problem. ROWTYPE_MISMATCH The host cursor variable and PL/SQL cursor variable involved in an assignment have incompatible return types. For example, when an open host cursor variable is passed to a stored subprogram, the return types of the actual and formal parameters must be compatible. SELF_IS_NULL A program attempts to call a MEMBER method, but the instance of the object type has not been initialized. The built-in parameter SELF points to the object, and is always the first parameter passed to a MEMBER method. STORAGE_ERROR PL/SQL runs out of memory or memory has been corrupted. SUBSCRIPT_BEYOND_COUNT A program references a nested table or varray element using an index number larger than the number of elements in the collection. SUBSCRIPT_OUTSIDE_LIMIT A program references a nested table or varray element using an index number (-1 for example) that is outside the legal range. SYS_INVALID_ROWID The conversion of a character string into a universal rowid fails
Re: [HACKERS] plpgsql compile error on win32
Magnus Hagander [EMAIL PROTECTED] writes: pg_strcasecmp is *not* included in libpostgres.a. It is in port/libpgport.a, though. (It's also in postgres.exe, but we don't link against that..) What do you mean we don't link against that? There must be hundreds of functions in the main backend that plpgsql.dll needs to call. How is it resolving the rest of them? 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] plpgsql compile error on win32
pg_strcasecmp is *not* included in libpostgres.a. It is in port/libpgport.a, though. (It's also in postgres.exe, but we don't link against that..) What do you mean we don't link against that? There must be hundreds of functions in the main backend that plpgsql.dll needs to call. How is it resolving the rest of them? Isn't that what libpostgres.a is used for? (double-checks) Ok. Egg on face. libpostgres.a is just the import library for postgres.exe. I knew that. It just slipped my mind at a bad time. Ok. So the problem is that functions from libpgport aren't included in postgres.def, and thus not in libpostgres.a. It seems that can be fixed with the following patch, which is probably a whole lot close to being right than what I did before: *** Makefile21 Jul 2004 20:34:44 - 1.103 --- Makefile31 Jul 2004 20:03:08 - *** *** 66,72 rm -f [EMAIL PROTECTED] [EMAIL PROTECTED] postgres.def: $(OBJS) ! $(DLLTOOL) --export-all --output-def $@ $^ libpostgres.a: postgres.def $(DLLTOOL) --dllname postgres.exe --def postgres.def --output-lib $@ --- 66,72 rm -f [EMAIL PROTECTED] [EMAIL PROTECTED] postgres.def: $(OBJS) ! $(DLLTOOL) --export-all --output-def $@ $^ $(top_builddir)/src/port/libpgport.a libpostgres.a: postgres.def $(DLLTOOL) --dllname postgres.exe --def postgres.def --output-lib $@ //Magnus ---(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] plpgsql compile error on win32
Magnus Hagander [EMAIL PROTECTED] writes: Ok. So the problem is that functions from libpgport aren't included in postgres.def, and thus not in libpostgres.a. It seems that can be fixed with the following patch, which is probably a whole lot close to being right than what I did before: That one feels right to me. Any objections out there? regards, tom lane *** Makefile21 Jul 2004 20:34:44 - 1.103 --- Makefile31 Jul 2004 20:03:08 - *** *** 66,72 rm -f [EMAIL PROTECTED] [EMAIL PROTECTED] postgres.def: $(OBJS) ! $(DLLTOOL) --export-all --output-def $@ $^ libpostgres.a: postgres.def $(DLLTOOL) --dllname postgres.exe --def postgres.def --output-lib $@ --- 66,72 rm -f [EMAIL PROTECTED] [EMAIL PROTECTED] postgres.def: $(OBJS) ! $(DLLTOOL) --export-all --output-def $@ $^ $(top_builddir)/src/port/libpgport.a libpostgres.a: postgres.def $(DLLTOOL) --dllname postgres.exe --def postgres.def --output-lib $@ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Version Numbering -- The great debate
Folks, Well, we're past feature freeze and with one reservation we know what's in the next version. After talking to several people at OSCON, I want to revive a discussion: whether this is 7.5 or 8.0. We tabled that discussion in April pending a feature list. Even if Savepoints don't make it, we'll still have: Win32 Port LRU/Background Writer/Lazy Vacuum PITR Tablespaces AutoVacuum in backend $$dollar_quoting$$ Re-typing columns New PL/perl CSV import/export This is more features worth mentioning than we've ever had in a single release before -- and if you consider several add-ons which have been implemented/improved at the same time (Slony, PL/Java, etc.) it's even more momentous. If this isn't 8.0, then what will be? I talked to a few of our people at OSCON who agreed with me. We'd need to settle this before we officially enter beta. Responses? -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Version Numbering -- The great debate
Josh Berkus wrote: This is more features worth mentioning than we've ever had in a single release before We've also never had a single release before that had its version number jump determined by the number of features. I talked to a few of our people at OSCON who agreed with me. We'd need to settle this before we officially enter beta. Responses? Considering that beta starts in about 3 hours -- 7.5 it is. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] About pgevent
If pgevent is a DLL, why is it in src/bin? We cannot have binary files like MSG1.bin in our source tree, no matter how convenient it is. The distributors are going to kill us for that. Please find another way. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Version Numbering -- The great debate
Peter, We've also never had a single release before that had its version number jump determined by the number of features. That's a non-argument, Peter; we don't have any clear criteria for version number jump. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] About pgevent
If pgevent is a DLL, why is it in src/bin? We cannot have binary files like MSG1.bin in our source tree, no matter how convenient it is. The distributors are going to kill us for that. Please find another way. The discussion back when it was decided weighted things back and forth. The main thing is that we'd include an extra build dependency for win32, which would be the Microsoft toolkit, several hundred Mb to download just to build a 32 byte file. What distributors would kill us for that, and why? The file is only ever built (indeed, the whole directory is only *entered*) on win32. //Magnus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Version Numbering -- The great debate
Josh Berkus wrote: We've also never had a single release before that had its version number jump determined by the number of features. That's a non-argument, Peter; we don't have any clear criteria for version number jump. Oh yes, we have very clear criteria: For patch releases, we increase the third number, for feature releases we increase the second number and set the third number to zero. Clear enough? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] About pgevent
Magnus Hagander wrote: The discussion back when it was decided weighted things back and forth. The main thing is that we'd include an extra build dependency for win32, which would be the Microsoft toolkit, several hundred Mb to download just to build a 32 byte file. Think about what open source means. It doesn't mean that we give our users binary blobs compiled on some guy's machine, because it's too inconvenient to obtain the build tools. If it's too inconvenient to obtain build tools, you use a binary distribution anyway. On closer inspection this stuff should probably be moved to src/utils in any case. It's clearly not a user binary, so it doesn't belong under src/bin. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] Version Numbering -- The great debate
Peter, Oh yes, we have very clear criteria: For patch releases, we increase the third number, for feature releases we increase the second number and set the third number to zero. Clear enough? So, as far as you're concerned, there will never ever be an 8.0. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] About pgevent
The discussion back when it was decided weighted things back and forth. The main thing is that we'd include an extra build dependency for win32, which would be the Microsoft toolkit, several hundred Mb to download just to build a 32 byte file. Think about what open source means. It doesn't mean that we give our users binary blobs compiled on some guy's machine, because it's too inconvenient to obtain the build tools. If it's too inconvenient to obtain build tools, you use a binary distribution anyway. How is this so different from the fact that we distribute the configure script? People can just go download autoconf, right? Or flex/bison output files. If it's too inconvenient to obtain build tools, use a binary distribution. It's not like we don't provide the source. You can rebuild it if you want to. (Or just look at the file and realise it's probably nothing to worry about) On closer inspection this stuff should probably be moved to src/utils in any case. It's clearly not a user binary, so it doesn't belong under src/bin. Yeah, that doesn't sounds all wrong. It is of course a different issue alltogether... I *think* (but can't say I know) that the reason it went into src/bin was that there is no actual place for generic libs. interfaces and pl are, well, interfaces and pls. And utils/ don't currently install things. But it could certainly be moved there and installed from there, doesn't really matter. //Magnus ---(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] Version Numbering -- The great debate
On Sun, Aug 01, 2004 at 12:02:47AM +0200, Peter Eisentraut wrote: Josh Berkus wrote: We've also never had a single release before that had its version number jump determined by the number of features. That's a non-argument, Peter; we don't have any clear criteria for version number jump. Oh yes, we have very clear criteria: For patch releases, we increase the third number, for feature releases we increase the second number and set the third number to zero. Clear enough? What was the rule for increasing the first number after just before 7.0? -- Alvaro Herrera ([EMAIL PROTECTED]) Vivir y dejar de vivir son soluciones imaginarias. La existencia está en otra parte (Andre Breton) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Version Numbering -- The great debate
Josh Berkus wrote: So, as far as you're concerned, there will never ever be an 8.0. Eventually we'll do the Sun switcheroo and follow release 7.12 by 13.0. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] Version Numbering -- The great debate
Alvaro Herrera wrote: What was the rule for increasing the first number after just before 7.0? That was just to avoid having to release a 6.6.6, which Jan had clearly been working towards. :-) Seriously, major version jumps correspond to epoch-like changes, like when the code moved out of Berkeley, or when we switched from bug fixing to adding features. Maybe the next epoch would be after a hostile takeover of firebird. But right now I see no epoch change, just a potential for confusing users. Consistency and humbleness can be a virtue. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Version Numbering -- The great debate
Josh Berkus [EMAIL PROTECTED] writes: Even if Savepoints don't make it, we'll still have: Savepoints are in, as is exception-trapping in functions (at least plpgsql, the other PLs are on their own :-(). Some other major improvements you didn't mention: Cross-datatype comparisons are indexable (at least for common combinations); this solves a huge performance gotcha Dependency-aware pg_dump Much more complete support for rowtype operations This is more features worth mentioning than we've ever had in a single release before -- and if you consider several add-ons which have been implemented/improved at the same time (Slony, PL/Java, etc.) it's even more momentous. If this isn't 8.0, then what will be? I tend to agree, and was about to bring up the point myself. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] About pgevent
Peter Eisentraut [EMAIL PROTECTED] writes: Think about what open source means. It doesn't mean that we give our users binary blobs compiled on some guy's machine, because it's too inconvenient to obtain the build tools. If it's too inconvenient to obtain build tools, you use a binary distribution anyway. If I understand what the README is saying, pgmsgevent.mc is the source file (the preferred form for modification), and MSG1.bin is just prebuilt output from it. It's unpleasant that it's not text, but I don't see that this is fundamentally different from providing configure along with configure.in. 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] try/catch macros for Postgres backend
On 07/28/04:30/3, Tom Lane wrote: In service of the refactoring of error handling that I was talking about a few days ago, I'm finding that there are several places that really ought to catch longjmps and clean up after themselves, instead of expecting that whatever mess they've made will be cleaned up for them when control gets back to PostgresMain(). If we have functions that can catch errors, control might *not* go right back to PostgresMain(), and so throwing random cleanup actions into the sigsetjmp branch there is No Good. This is wonderful news. plpy for 7.5 will be very nice. :) This is no big deal since pltcl and plpython already do much the same thing, but I'm starting to think that instead of directly hacking on Warn_restart, it would be good to have some macros hiding the details. The syntax I'm toying with is ... Does anyone have a problem with this macro syntax? The try/catch names are stolen from Java, so I'm figuring they won't terribly surprise any modern programmer, but I'm open to different names if anyone has a better idea. Sounds good, but perhaps it would be useful for some developers to have the macro syntax broken up into smaller pieces, plpythonu does/did this in plpython.h(gone now), and I rolled my own based on plpython's in plpy. for example: #define PG_EXC_DECLARE() sigjmp_buf local_sigjmp_buf #define PG_EXC_SAVE() \ sigjmp_buf *save_exception_stack = PG_exception_stack; \ ErrorContextCallback *save_context_stack = error_context_stack #define PG_EXC_TRAP() (sigsetjmp(local_sigjmp_buf, 1) == 0) ... You could then use those to make up PG_TRY, PG_CATCH, PG_END_TRY. Although, I'm not too concerned about this, as if someone wants the smaller pieces they could probably just write their own without much difficulty. Also, the memcpy technique for saving/restoring Warn_restart is what pltcl and plpython currently use, and it works, but it seems unnecessarily inefficient. A further improvement would be to replace Warn_restart by a pointer defined like extern sigjmp_buf *exception_stack_top; Aye, good idea. -- Regards, James William Pye pgpVR2RlKrgUv.pgp Description: PGP signature
Re: [HACKERS] Version Numbering -- The great debate
Peter Eisentraut [EMAIL PROTECTED] writes: Alvaro Herrera wrote: What was the rule for increasing the first number after just before 7.0? That was just to avoid having to release a 6.6.6, which Jan had clearly been working towards. :-) AFAIR, we had informally been referring to that release as 6.6 right up until about the start of beta, when it was proposed that it should be called 7.0 because of the extent of the changes since 6.5, and that motion carried. If we decide now to rename 7.5 to 8.0, it will be exactly the same process. I don't think Peter's process-based objections are valid at all. It strikes me that we have more than enough major changes since 7.4 to justify calling this 8.0, both in terms of major features that users have been asking for, and in terms of the extent of internal reorganization (and consequent need for beta testing ...). Seriously, major version jumps correspond to epoch-like changes, like when the code moved out of Berkeley, or when we switched from bug fixing to adding features. Two commments about that. One, I think you are engaging in historical revisionism about the reason for the 6.6/7.0 renaming. I don't recall that 7.0 marked any particular watershed in terms of our general bug level, nor that we saw it in those terms when we decided to renumber. Two, I think 7.5/8.0 will indeed be epochal in terms of the size of our user community. Win32 native support will mean a great deal on the low end, and savepoints, PITR, and reliable replication (Slony) will mean a great deal in terms of our credibility as an enterprise-class database. regards, tom lane PS: IIRC I was on the nay side in the 6.6-to-7.0 rename vote, so I think I definitely have standing to be in favor this time. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] try/catch macros for Postgres backend
James William Pye [EMAIL PROTECTED] writes: On 07/28/04:30/3, Tom Lane wrote: Does anyone have a problem with this macro syntax? The try/catch names are stolen from Java, so I'm figuring they won't terribly surprise any modern programmer, but I'm open to different names if anyone has a better idea. Sounds good, but perhaps it would be useful for some developers to have the macro syntax broken up into smaller pieces, plpythonu does/did this in plpython.h(gone now), and I rolled my own based on plpython's in plpy. Is there any actual functional usefulness to that, or is it just to avoid having to reorder existing code to fit into the try/catch paradigm? I would actually prefer to force people to use the try/catch macros, in the name of code readability and consistent coding style. I had never felt that I understood the way the plpython error-trapping code was structured, until I had to go in and examine it in detail to rewrite it into the try/catch style. I think it's now a lot more legible to the casual reader, and that's an important goal for Postgres-related code. for example: #define PG_EXC_DECLARE() sigjmp_buf local_sigjmp_buf #define PG_EXC_SAVE() \ sigjmp_buf *save_exception_stack = PG_exception_stack; \ ErrorContextCallback *save_context_stack = error_context_stack #define PG_EXC_TRAP() (sigsetjmp(local_sigjmp_buf, 1) == 0) If you're really intent on doing that, you probably can do it no matter what I say about it ;-). But I find it hardly any improvement over direct use of the setjmp API. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Trapping QUERY_CANCELED: yes, no, maybe?
You are asking if a funciton itself might want to set query cancel and catch the cancel and do something else? For 7.5 I would be happy just canceling the entire thing. --- Tom Lane wrote: Now that it is possible for plpgsql functions (and, no doubt, soon others) to trap errors, I think we need a little bit of discussion about what kind of restrictions should be put on trapping the QUERY_CANCELED error. If we treat QUERY_CANCELED as an absolutely ordinary error, it would be fairly easy for a carelessly written function to disable the backend from responding to ^C or statement_timeout --- it need only catch the error and keep on processing. On the other hand, it's not impossible to envision scenarios where you'd like to be able to catch QUERY_CANCELED. I can see people using that ability in combination with statement_timeout, in particular. The compromise that I put into plpgsql for the moment works like this: 1. EXCEPTION WHEN OTHERS THEN matches all error types *except* QUERY_CANCELED; thus you cannot accidentally catch that error. (When the EXCEPTION clause does not match the error type, the error just propagates outward, so QUERY_CANCELED will always force control back to the idle loop.) 2. But you can explicitly say EXCEPTION WHEN QUERY_CANCELED THEN if you really want to catch it. I can see that point #2 might be controversial, and that some might feel that QUERY_CANCELED should be untrappable, period. Does anyone want to argue for that? Does anyone think #1 is a bad idea? There is also an implementation-level issue, which is whether we should rely on the PLs' individual error handlers (which are mostly yet to be written) to enforce such policies consistently. As long as QUERY_CANCELED is the only special case, things aren't too bad, but if there's any prospect of having more special cases it could get messy. I thought about inventing a new elevel category, but really that does not help much, since we'd still be dependent on the error handlers to be cooperative. (We can't not run the handlers, since there is very likely state that they *must* undo before losing control.) Anyone see a cleaner approach? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- 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 7: don't forget to increase your free space map settings
Re: [HACKERS] Version Numbering -- The great debate
I am fine with either numbering, but I think the 8.0 might make more sense. --- Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Alvaro Herrera wrote: What was the rule for increasing the first number after just before 7.0? That was just to avoid having to release a 6.6.6, which Jan had clearly been working towards. :-) AFAIR, we had informally been referring to that release as 6.6 right up until about the start of beta, when it was proposed that it should be called 7.0 because of the extent of the changes since 6.5, and that motion carried. If we decide now to rename 7.5 to 8.0, it will be exactly the same process. I don't think Peter's process-based objections are valid at all. It strikes me that we have more than enough major changes since 7.4 to justify calling this 8.0, both in terms of major features that users have been asking for, and in terms of the extent of internal reorganization (and consequent need for beta testing ...). Seriously, major version jumps correspond to epoch-like changes, like when the code moved out of Berkeley, or when we switched from bug fixing to adding features. Two commments about that. One, I think you are engaging in historical revisionism about the reason for the 6.6/7.0 renaming. I don't recall that 7.0 marked any particular watershed in terms of our general bug level, nor that we saw it in those terms when we decided to renumber. Two, I think 7.5/8.0 will indeed be epochal in terms of the size of our user community. Win32 native support will mean a great deal on the low end, and savepoints, PITR, and reliable replication (Slony) will mean a great deal in terms of our credibility as an enterprise-class database. regards, tom lane PS: IIRC I was on the nay side in the 6.6-to-7.0 rename vote, so I think I definitely have standing to be in favor this time. ---(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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Trapping QUERY_CANCELED: yes, no, maybe?
Bruce Momjian [EMAIL PROTECTED] writes: You are asking if a funciton itself might want to set query cancel and catch the cancel and do something else? Exactly. There's a proof-of-concept test at the bottom of regress/sql/plpgsql.sql, wherein a function gets control back from a query that would have run for an unreasonably long time. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Version Numbering -- The great debate
Hello, Version 7.5 is as close to a major release as I have seen in the almost 9 years I have been using PostgreSQL. This release brings about a lot of "enterprise" features that have been holding back PostgreSQL in a big way for for a long time. All of my serious customers; potential, existing and past has all at one point or another requested most if not all of the features being released onto the world with 7.5. In fact the only ones that I can think of off the top of my head that isn't in the current list of availables is table partitioning and to a lesser extent two phase commit. This release definately deserves a major version jump. If it were up to me it would be more than one (I would call it 10h for obvious reasons. O.k. the h is a joke but I am serious about the 10) just from a marketing standpoint. I could argue a major version jump just from the fact that we finally have a port to the most used operating system (regardless if that is good or bad) in the world. Sincerely, Joshua D. Drake Tom Lane wrote: Josh Berkus [EMAIL PROTECTED] writes: Even if Savepoints don't make it, we'll still have: Savepoints are in, as is exception-trapping in functions (at least plpgsql, the other PLs are on their own :-(). Some other major improvements you didn't mention: Cross-datatype comparisons are indexable (at least for common combinations); this solves a huge performance gotcha Dependency-aware pg_dump Much more complete support for rowtype operations This is more features worth mentioning than we've ever had in a single release before -- and if you consider several add-ons which have been implemented/improved at the same time (Slony, PL/Java, etc.) it's even more momentous. If this isn't 8.0, then what will be? I tend to agree, and was about to bring up the point myself. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Re: [HACKERS] try/catch macros for Postgres backend
On 07/31/04:30/6, Tom Lane wrote: Is there any actual functional usefulness to that, or is it just to avoid having to reorder existing code to fit into the try/catch paradigm? Both, I imagine. In the case of the former, it *may be* useful for someone to create their own paradigm, which seems like it would tye back into the latter. I would actually prefer to force people to use the try/catch macros, in the name of code readability and consistent coding style. Ah, you must be a Python programmer at heart! ;) I had never felt that I understood the way the plpython error-trapping code was structured, until I had to go in and examine it in detail to rewrite it into the try/catch style. Yeah, it wasn't pretty. When I first started on plpy, I hadn't even heard of sigjmp_buf before. Perhaps you can imagine the clumps of hair I had to pull out to finally get a grasp on it. I think it's now a lot more legible to the casual reader, and that's an important goal for Postgres-related code. Definitely. It is a vast improvement over plpython's more demanding style. If you're really intent on doing that, you probably can do it no matter what I say about it ;-). I have yet to decide to adopt the new syntax, as I just saw it yesterday, but it is likely that I will, as I do depend on PG, so if it convenient, I might as well use the tools that it gives me. But I find it hardly any improvement over direct use of the setjmp API. Well, I find it more aesthetically appealing, and it can be quite nice to have a macro interface to allow the underlying to change willy-nilly(not that it should, but that it can). I'll bet that's the hardly any improvement that you mentioned. -- Regards, James William Pye pgp1kRiCAv5XB.pgp Description: PGP signature
Re: [HACKERS] Version Numbering -- The great debate
So, as far as you're concerned, there will never ever be an 8.0. Eventually we'll do the Sun switcheroo and follow release 7.12 by 13.0. How about 7.5i :) Chris ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Version Numbering -- The great debate
This is more features worth mentioning than we've ever had in a single release before -- and if you consider several add-ons which have been implemented/improved at the same time (Slony, PL/Java, etc.) it's even more momentous. If this isn't 8.0, then what will be? I tend to agree, and was about to bring up the point myself. I'm in favour of 8.0. There's a time to be humble and a time for hard work to be properly recognised. Chris ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] initdb problem
Ah, just the person I was looking for. I see in the initdb po file you sent that the use of backslashes in the message string is causing some of us problems. What are the rules for backslashes in translation files? I particularly had problems with lines 199, 260, and 461 in the initdb po file because you had things like: XXX\\n where XXX were high-bit characters. Was that correct? It caused us problems because it interpreted \\ as a single backslash and then complained because the message id and string had a different number of newlines. --- Zhenbang Wei wrote: Thanks for importing these translations :-) [ 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 8: explain analyze is your friend
Re: [HACKERS] Version Numbering -- The great debate
Christopher Kings-Lynne wrote: This is more features worth mentioning than we've ever had in a single release before -- and if you consider several add-ons which have been implemented/improved at the same time (Slony, PL/Java, etc.) it's even more momentous. If this isn't 8.0, then what will be? I tend to agree, and was about to bring up the point myself. I'm in favour of 8.0. There's a time to be humble and a time for hard work to be properly recognized. FYI, the move to 7.0 was done after we realized that 6.5 should have been numbered 7.0. -- 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: [HACKERS] initdb problem
Some characters in Big5 encoding has a / on second byte and I think poEdit will add another / for me. Now I think I should use UTF-8 instead of Big5. I will send new files in minutes. Sorry for causing problems. On Sun, 1 Aug 2004 00:48:21 -0400 (EDT), Bruce Momjian [EMAIL PROTECTED] wrote: Ah, just the person I was looking for. I see in the initdb po file you sent that the use of backslashes in the message string is causing some of us problems. What are the rules for backslashes in translation files? I particularly had problems with lines 199, 260, and 461 in the initdb po file because you had things like: XXX\\n where XXX were high-bit characters. Was that correct? It caused us problems because it interpreted \\ as a single backslash and then complained because the message id and string had a different number of newlines. --- Zhenbang Wei wrote: Thanks for importing these translations :-) [ 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] initdb problem
The big problem is that it didn't add an extra \ in the cases I mentioned. There were other strings that looked like: XXX\XX where X is a high-bit character. Notice there is only one backslash. --- Zhenbang Wei wrote: Some characters in Big5 encoding has a / on second byte and I think poEdit will add another / for me. Now I think I should use UTF-8 instead of Big5. I will send new files in minutes. Sorry for causing problems. On Sun, 1 Aug 2004 00:48:21 -0400 (EDT), Bruce Momjian [EMAIL PROTECTED] wrote: Ah, just the person I was looking for. I see in the initdb po file you sent that the use of backslashes in the message string is causing some of us problems. What are the rules for backslashes in translation files? I particularly had problems with lines 199, 260, and 461 in the initdb po file because you had things like: XXX\\n where XXX were high-bit characters. Was that correct? It caused us problems because it interpreted \\ as a single backslash and then complained because the message id and string had a different number of newlines. --- Zhenbang Wei wrote: Thanks for importing these translations :-) [ 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 -- 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
[HACKERS] TODO improvements
I have added descriptions to many TODO items. I need help with all the items marked with question marks. Please post your comment and CVS committers are welcome to modify it directly. -- 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] Version Numbering -- The great debate
On Sun, Aug 01, 2004 at 12:20:59PM +0800, Christopher Kings-Lynne wrote: This is more features worth mentioning than we've ever had in a single release before -- and if you consider several add-ons which have been implemented/improved at the same time (Slony, PL/Java, etc.) it's even more momentous. If this isn't 8.0, then what will be? I tend to agree, and was about to bring up the point myself. I'm in favour of 8.0. There's a time to be humble and a time for hard work to be properly recognised. We deploy postgresql as part of an application that goes out to big, IT-savvy corporations. So far we've shipped 7.2.* and 7.4.* (the upgrade pain to 7.3 outweighed the benefits, so we put that off and put it off until 7.4 was available). 8.0.0 suggests, to my customers at least, a brand new release with either massive re-architecting, many new features or both and that's likely to be riddled with bugs. While it would be unlikely that we'd ship 7.5.0 to customers (I suspect there'd be a .1 release before we were comfortable with the .0 release, given the massive changes) there's not a chance we'd ship 8.0.0 - even though it's the identical codebase - because of that perception. Probably not 8.0.1 either. From the discussions I've seen and the number and size of changes I've seen go into the codebase recently I suspect 8.0.0 might be quite an appropriate version number on several levels. There have been a lot of major changes in this release, some significant enough, I think, anyway, to justify a bump in major version number. Those major changes touch the code everywhere (especially nested transactions - where the breadth of the changes scares me) and are likely to lead to a number of obscure bugs that will be problematic and will probably survive through an extended beta period. People are likely to expect more bugs in a .0.0 release - but that also means they're likely to be much more tolerant of them (nice functionality, but some problematic bugs - but it's a .0.0 release, so we expect some bugs, but we also expect the .0.2 or .1.0 release to be _really_ good.). So, from a managing customer expectations POV, 8.0.0 looks an appropriate version number for at least two major reasons. I'd rather end-users treat this release as a development/preview release, forgive the bugs and take a minor release or two before expecting the level of stability _we_ expect from postgresql - and I suspect that may be doubly appropriate for the large base of potential win32 users. Just a perspective from a company that uses and redistributes PostgreSQL to end-users. Cheers, Steve ---(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
