Re: [HACKERS] Release notes introductory text
Kevin Grittner wrote: How exactly do you expect the software to get from a .0 to a .1 release, or to have addressed the bugs that might bite you when it does get to .1, if you aren't helping to test it? In most environments I've seen, developer and QA systems don't hesitate to move to .0 releases (or even beta). I agree with Joshua that it's nerve wracking to move _production_ systems to .0 releases from most software vendors. My philosophy is that the final QA environment should be as close to the production environment as can be arranged, but that difference in the development and initial test environments contribute to robustness. Sorry if I implied otherwise - I was assuming an environment where QA has multiple environments; one of which clearly should be the same as production. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: Add sample text search dictionary templates and parsers, to
On Mon, Oct 15, 2007 at 07:17:12PM -0400, Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Looks like dict-xsyn needs some windows install help for the rules file. Ah, I was afraid of that :-(. The bespoke rule for installing that file looked like trouble but I forgot about it while looking at the rest of the code. It doesn't seem like teaching Mkvcbuild.pm about this specific file would be a real good plan. Can we get the DATA macro to handle it somehow? It's not going into the toplevel SHAREDIR --- will a relative path work? The msvc Install.pm file (not Mkvcbuild in this case) will put it in /share/contrib/, and currently doesn't support subdirs. But it can bemade to support those if needed, I guess. No idea if that'll work on non-msvc builds. Do we expect there might be more like this? We could easily add a rule to Install.pm to know about DICTFILES rules in addition to DATA rules.. (In CopyContribFiles in Install.pm) //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Why copy_relation_data only use wal when WAL archiving is enabled
If I run the database under non-archiving mode, and execute the following command: alter table t set tablespace tblspc1; Isn't it possible that the new t cann't be recovered? ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Why copy_relation_data only use wal when WAL archiving is enabled
Jacky Leng wrote: If I run the database under non-archiving mode, and execute the following command: alter table t set tablespace tblspc1; Isn't it possible that the new t cann't be recovered? No. At the end of copy_relation_data we call smgrimmedsync, which fsyncs the new relation file. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Windows and locales and UTF-8 (oh my)
On Mon, Oct 15, 2007 at 07:44:00PM +0200, Magnus Hagander wrote: Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Tom Lane wrote: Hmm. If it doesn't need a special case, then we still lack an explanation for the aforementioned bug report. From what I can tell that report doesn't tell us very much - we don't know server encoding, we don't know server locale, we don't even know client encoding. So I don't think we know anywhere *near* enough to say it's related to this. In the followup we found out that he was using UTF-8 encoding: http://archives.postgresql.org/pgsql-bugs/2007-05/msg00264.php So while that report certainly left a great deal to be desired in terms of precision, my gut tells me it's related. Has anyone tried to reproduce that behavior by initdb'ing 8.2 in a suitable UTF-8-using Windows locale? It doesn't tell us if it's the client or the server that's in UTF8, and it doesn't tell us about the locale. Euler Taveira de Oliveira's response says he can't reproduce it. I haven't tried myself, and that webpage really doesn't tell us what what the character is. If someone can comment on that, I can try to repro it on my systems. Got some help on IRC to dentify the charafters as ç and Ç. I can confirm that both work perfectly fine with UTF-8 and locale Swedish_Sweden.1252. They sort correctly, and they work with both upper() and lower() correctly. This test is with 8.3-HEAD and the patch to allow UTF-8. This leads me to beleive that something is wrong with the ops system. Most likely it's just the client that's in UTF8 mode, and the server is SQL_ASCII. //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] support for hyper-long transactions ...
at the moment i am working on an application which is supposed to run extremely large transactions (a lot of server side stored procedure stuff which can hardly be split into small transactions for visibility reasons). so, from time to time it happens that i exceed my CommandCounter ( 2.000.000.000 statements inside the same transaction). my idea is: how about adding a configure option to compile postgres with a 64 bit command counter. this would allow larger transactions for special purpose applications while it would not have an impact on normal applications. comments are welcome ... best regards, hans -- Cybertec Schönig Schönig GmbH Gröhrmühlgasse 26, 2700 Wiener Neustadt Tel: +43/1/205 10 35 / 340 www.postgresql.at, www.cybertec.at
Re: [HACKERS] support for hyper-long transactions ...
Hans-Juergen Schoenig wrote: at the moment i am working on an application which is supposed to run extremely large transactions (a lot of server side stored procedure stuff which can hardly be split into small transactions for visibility reasons). so, from time to time it happens that i exceed my CommandCounter ( 2.000.000.000 statements inside the same transaction). Interesting. What kind of a stored procedure is that? One optimization that might be possible is to not increment it for statements that do on-disk changes. my idea is: how about adding a configure option to compile postgres with a 64 bit command counter. this would allow larger transactions for special purpose applications while it would not have an impact on normal applications. One objection to expanding TransactionId to 64-bits has been that we depend on assignment of TransactionId to be atomic. That might not be an issue with CommandIds; I don't think we store commandids in shared memory structures. It still doesn't feel like a good idea to me, though. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] support for hyper-long transactions ...
Hans-Juergen Schoenig wrote: at the moment i am working on an application which is supposed to run extremely large transactions (a lot of server side stored procedure stuff which can hardly be split into small transactions for visibility reasons). so, from time to time it happens that i exceed my CommandCounter ( 2.000.000.000 statements inside the same transaction). AFAICS, maximum number of command ids is actually 2^32-1, or over 4 billion. Are you sure you bumped into that limit and not something else? What's the error message you're getting? What version of Postgres is this? PG 8.3 will have another related limit on the number of combocids you can have. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] support for hyper-long transactions ...
Heikki Linnakangas írta: Hans-Juergen Schoenig wrote: at the moment i am working on an application which is supposed to run extremely large transactions (a lot of server side stored procedure stuff which can hardly be split into small transactions for visibility reasons). so, from time to time it happens that i exceed my CommandCounter ( 2.000.000.000 statements inside the same transaction). Interesting. What kind of a stored procedure is that? One optimization that might be possible is to not increment it for statements that do on-disk changes. my idea is: how about adding a configure option to compile postgres with a 64 bit command counter. this would allow larger transactions for special purpose applications while it would not have an impact on normal applications. One objection to expanding TransactionId to 64-bits has been that we depend on assignment of TransactionId to be atomic. That might not be an issue with CommandIds; I don't think we store commandids in shared memory structures. It still doesn't feel like a good idea to me, though. Isn't 64-bit assignment atomic on 64-bit machines? With a little autoconf magic, the conditional can be disabled for 32-bit platforms. So that's not a real obstacle for going to 64-bit TransactionIds. -- -- Zoltán Böszörményi Cybertec Geschwinde Schönig GmbH http://www.postgresql.at/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] support for hyper-long transactions ...
AFAICS, maximum number of command ids is actually 2^32-1, or over 4 billion. Are you sure you bumped into that limit and not something else? What's the error message you're getting? What version of Postgres is this? PG 8.3 will have another related limit on the number of combocids you can have. it is clearly caused by the CommandCounter - it is indicated by the error message. i don't have the message on my notebook here but this is exactly what is going on if we run out of statements. i would not see atomic as a problem here as we can support it for 64 bit boxes only. i would vote for some autoconf flag which is off by default to make sure that other applications don't waste space here. to answer the question you had before: it is an application going through some enormous amount of raw data and trying to do some filtering, analysis and preaggregation (which is not an issue here). the thing is that filtering and analysis are quite complex and have to be done on a per entry level (a lot of conditional lookups, if statements, custom aggregated, status changed and so on). if you are forced to do this fancy logic for 1xx mio records you can easily run out of commands. many thanks, hans -- Cybertec Schönig Schönig GmbH Gröhrmühlgasse 26, 2700 Wiener Neustadt Tel: +43/1/205 10 35 / 340 www.postgresql.at, www.cybertec.at
Re: [HACKERS] [COMMITTERS] pgsql: Add sample text search dictionary templates and parsers, to
Magnus Hagander [EMAIL PROTECTED] writes: Do we expect there might be more like this? We could easily add a rule to Install.pm to know about DICTFILES rules in addition to DATA rules.. Yeah, after sleeping on it I think we need a general-purpose solution. There are likely to be more not fewer tsearch-related contrib modules in future; and even if you don't believe that, people will certainly want to use the PGXS infrastructure to build add-on dictionaries. So we should provide a DATA-like macro to specify installing stuff into $SHAREDIR/tsearch_data/, instead of making everyone reinvent the hack that's currently in dict_xsyn/Makefile. I was going to propose calling it DATA_TSEARCH, but DICTFILES would work too. Any preferences? regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] [RFC] extended txid docs
Although the new txid functions are very clean 1:1 interface to the internal MVCC info and they don't need much docs in that respect, their killer usage comes from the possibility to query txids committed between 2 snapshots. But how to do that (efficiently) is far from obvious when just looking at the API. So with attached docs patch I try to fill the gap. Here I also show 2 variants for the common query helper function. But I'm pretty bad at SGML, english and writing docs, so please review it. In addition to english/typos/sgml the suspicious aspects are: - code style - writing style - used mostly PgQ terminology (ticks), could there be something better? - giving two variants of helper function may be too much Even the realistic code may be too much for general docs, but considering this is not a functionality covered by general SQL textbooks, I think it is worth having. I also put rendered pages up here: http://skytools.projects.postgresql.org/txid/datatype-txid-snapshot.html http://skytools.projects.postgresql.org/txid/functions-txid.html -- marko txid-docs.diff.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 1: 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] Indiana changes DST (4th Nov)
There are a lot of incoming DST or TZ changes (Venezuela, Brazil, Indiana...). Most hot is Indiana which will happen at 4th Nov. http://www.worldtimezone.com/dst_news/dst_news_usa02.html Is there any schedule to release new minor versions? It seems that new Olson database is in CVS repository and 8.3beta1 contains these changes. Zdenek ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: Add sample text search dictionary templates and parsers, to
On Tue, Oct 16, 2007 at 10:05:27AM -0400, Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Do we expect there might be more like this? We could easily add a rule to Install.pm to know about DICTFILES rules in addition to DATA rules.. Yeah, after sleeping on it I think we need a general-purpose solution. There are likely to be more not fewer tsearch-related contrib modules in future; and even if you don't believe that, people will certainly want to use the PGXS infrastructure to build add-on dictionaries. So we should provide a DATA-like macro to specify installing stuff into $SHAREDIR/tsearch_data/, instead of making everyone reinvent the hack that's currently in dict_xsyn/Makefile. I was going to propose calling it DATA_TSEARCH, but DICTFILES would work too. Any preferences? DATA_TSEARCH seems better, it indicates where the files are going even clearer. //Magnus ---(end of broadcast)--- TIP 1: 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] Indiana changes DST (4th Nov)
Zdenek Kotala wrote: There are a lot of incoming DST or TZ changes (Venezuela, Brazil, Indiana...). Most hot is Indiana which will happen at 4th Nov. http://www.worldtimezone.com/dst_news/dst_news_usa02.html Is there any schedule to release new minor versions? It seems that new Olson database is in CVS repository and 8.3beta1 contains these changes. Did you see Postgres release 8.2.5, released 2007-09-17? -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: 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] Indiana changes DST (4th Nov)
Zdenek Kotala [EMAIL PROTECTED] writes: There are a lot of incoming DST or TZ changes (Venezuela, Brazil, Indiana...). Most hot is Indiana which will happen at 4th Nov. Indiana is moving a few counties from one side of the line to another. The rules for the zones themselves aren't changing, so I'm not sure we can do anything to help them. Actually that's kind of weird, it means any timestamps in your database will display with the new timezone even though they occurred in the old one. And if you do time arithmetic with things like now() - '7 days' you'll get the output in the wrong timezone. Does the database acquire new timezones for these counties with the rule for when they changed? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: Add sample text search dictionary templates and parsers, to
Magnus Hagander [EMAIL PROTECTED] writes: DATA_TSEARCH seems better, it indicates where the files are going even clearer. Done. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Indiana changes DST (4th Nov)
Bruce Momjian wrote: Zdenek Kotala wrote: There are a lot of incoming DST or TZ changes (Venezuela, Brazil, Indiana...). Most hot is Indiana which will happen at 4th Nov. http://www.worldtimezone.com/dst_news/dst_news_usa02.html Is there any schedule to release new minor versions? It seems that new Olson database is in CVS repository and 8.3beta1 contains these changes. Did you see Postgres release 8.2.5, released 2007-09-17? You have right. I overlooked correct tag in CVS repository. It contains correct version. Can we put more info to the release notes? For example - Timezone database was updated to tzdata2007h also add this actual version info into src/timezone/README should help. There is only mention about New Zealand and is difficult to find this information. Thanks Zdenek ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Indiana changes DST (4th Nov)
Gregory Stark [EMAIL PROTECTED] writes: Does the database acquire new timezones for these counties with the rule for when they changed? Historically that's been what the zic folks did anytime a region that had been all one timezone rule diverged. I can't see any indication in the current northamerica file of a change that first takes effect this fall, though. It does reflect changes of this sort in Indiana that took effect last fall and this spring ... all of which were already in our last releases. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
[EMAIL PROTECTED] (Magnus Hagander) writes: Re-allow UTF8 encodings on win32. Since UTF8 is converted to UTF16 before being used, all (valid) locales will work for this. So where do we stand on the Windows locale/encoding business --- are we happy with the behavior now, or does it still need work? regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
Tom Lane wrote: [EMAIL PROTECTED] (Magnus Hagander) writes: Re-allow UTF8 encodings on win32. Since UTF8 is converted to UTF16 before being used, all (valid) locales will work for this. So where do we stand on the Windows locale/encoding business --- are we happy with the behavior now, or does it still need work? I think we're good. But I'd like to hear some verification from somebody else. Specifically, I'd like to hear a signoff from someone who can actually do real tests on a locale that's not US and not Swedish. Also, I'd like to hear from the Japanese people (Hiroshi? Can you do this?) that we didn't break it for them. I don't think we did, but I want to be sure :) Hiroshi, and whomever else can help to test, this is only testing the backend, not the installer. The installer may need a few minor tweaks still once the backend is considered fixed. And what needs to be tested is CVS HEAD as of today. //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
Hi. Um, It seems that it only passed the strict check of chklocale.c. Probably, It may enable mistaken selection...However, I will clarify a problem by the test. Regards, Hiroshi Saito From: Magnus Hagander [EMAIL PROTECTED] Tom Lane wrote: [EMAIL PROTECTED] (Magnus Hagander) writes: Re-allow UTF8 encodings on win32. Since UTF8 is converted to UTF16 before being used, all (valid) locales will work for this. So where do we stand on the Windows locale/encoding business --- are we happy with the behavior now, or does it still need work? I think we're good. But I'd like to hear some verification from somebody else. Specifically, I'd like to hear a signoff from someone who can actually do real tests on a locale that's not US and not Swedish. Also, I'd like to hear from the Japanese people (Hiroshi? Can you do this?) that we didn't break it for them. I don't think we did, but I want to be sure :) Hiroshi, and whomever else can help to test, this is only testing the backend, not the installer. The installer may need a few minor tweaks still once the backend is considered fixed. And what needs to be tested is CVS HEAD as of today. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
2007/10/16, Magnus Hagander [EMAIL PROTECTED]: Tom Lane wrote: [EMAIL PROTECTED] (Magnus Hagander) writes: Re-allow UTF8 encodings on win32. Since UTF8 is converted to UTF16 before being used, all (valid) locales will work for this. So where do we stand on the Windows locale/encoding business --- are we happy with the behavior now, or does it still need work? I think we're good. But I'd like to hear some verification from somebody else. Specifically, I'd like to hear a signoff from someone who can actually do real tests on a locale that's not US and not Swedish. Also, I'd like to hear from the Japanese people (Hiroshi? Can you do this?) that we didn't break it for them. I don't think we did, but I want to be sure :) Hiroshi, and whomever else can help to test, this is only testing the backend, not the installer. The installer may need a few minor tweaks still once the backend is considered fixed. And what needs to be tested is CVS HEAD as of today. //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match I can test it with czech locale. Can I download binaries anywhere? Pavel ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
Hi. I can test it with czech locale. Can I download binaries anywhere? http://winpg.jp/~saito/pg83/postgresql-8.3beta-cvs.tgz It is a thing after regression test.(MinGW+gcc) Regards, Hiroshi Saito ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
Hi. Um, It seems that it only passed the strict check of chklocale.c. Probably, It may enable mistaken selection...However, I will clarify a problem by the test. First, it is one problem http://winpg.jp/~saito/pg83/pg83b1-err.txt And a test continues ---(end of broadcast)--- TIP 1: 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] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
Hi. Second, it is big problem http://winpg.jp/~saito/pg83/pg83b1-err2.txt It is text serch config error. However, It passes initdb.(locale=Japanese_Japan.932 ... This is ShiftJIS locale) And a test continues Regards, Hiroshi Saito ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Proposal: PL/pgSQL EXECUTE INTO USING (for 8.4)
Hello, this proposal change older unaccepted proposal http://archives.postgresql.org/pgsql-hackers/2006-03/msg01157.php . Changes: * based on prepared statements * syntax and behave is near to Oracle * usable as protection from SQL injection New syntax: a) EXECUTE stringexpr [INTO [STRICT] varlist [USING exprlist] b) FOR varlist IN EXECUTE stringexpr USING exprlist LOOP Reason: * defence from SQL injection * more readable, shorter, more comfortable Sample (secure dynamic statement): EXECUTE 'SELECT * FROM ' || CASE tblname WHEN 'tab1' THEN 'tab1' WHEN 'tab2' THEN 'tab2' ELSE 'some is wrong' END || ' WHERE c1 = $1 AND c2 = $2' USING unsecure_parameter1, unsecure_parameter2; Difference between PL/SQL and proposal: * allow only IN variables * use PostgreSQL placeholders notation - $n instead :n Compliance with PL/SQL * You can use numeric, character, and string literals as bind arguments * You cannot use bind arguments to pass the names of schema objects to a dynamic SQL statement. Best regards Pavel Stehule ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
Hiroshi Saito wrote: Hi. Um, It seems that it only passed the strict check of chklocale.c. Probably, It may enable mistaken selection...However, I will clarify a problem by the test. First, it is one problem http://winpg.jp/~saito/pg83/pg83b1-err.txt And a test continues But SJIS isn't supposed to work, no? //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
Hiroshi Saito wrote: Hi. Second, it is big problem http://winpg.jp/~saito/pg83/pg83b1-err2.txt It is text serch config error. However, It passes initdb.(locale=Japanese_Japan.932 ... This is ShiftJIS locale) And a test continues What text search config would you expect? //Magnus ---(end of broadcast)--- TIP 1: 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] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
Hi. Hiroshi Saito wrote: Hi. Second, it is big problem http://winpg.jp/~saito/pg83/pg83b1-err2.txt It is text serch config error. However, It passes initdb.(locale=Japanese_Japan.932 ... This is ShiftJIS locale) And a test continues What text search config would you expect? This problem here is that locale of initdb passes Japanese_Japan.932. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
Hiroshi Saito wrote: Hi. Second, it is big problem http://winpg.jp/~saito/pg83/pg83b1-err2.txt It is text serch config error. However, It passes initdb.(locale=Japanese_Japan.932 ... This is ShiftJIS locale) And a test continues The changes that were made were only to re-enable UTF-8. SJIS wasn't ever supported as a server encoding (http://www.postgresql.org/docs/8.2/interactive/multibyte.html). The fact that initdb continues if you use Japanese_Japan.932 is an inconsistency I reported previously but has yet to be fixed. /D ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Proposal: PL/pgSQL EXECUTE INTO USING (for 8.4)
On 10/16/07, Pavel Stehule [EMAIL PROTECTED] wrote: Hello, this proposal change older unaccepted proposal http://archives.postgresql.org/pgsql-hackers/2006-03/msg01157.php . Compliance with PL/SQL * You can use numeric, character, and string literals as bind arguments * You cannot use bind arguments to pass the names of schema objects to a dynamic SQL statement. does this mean you can't dynamically sub in a variable for a table name? if so, why keep that limitation? one of the main reasons to use dynamic sql is for schema objects. merlin ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Proposal: PL/pgSQL EXECUTE INTO USING (for 8.4)
2007/10/16, Merlin Moncure [EMAIL PROTECTED]: On 10/16/07, Pavel Stehule [EMAIL PROTECTED] wrote: Hello, this proposal change older unaccepted proposal http://archives.postgresql.org/pgsql-hackers/2006-03/msg01157.php . Compliance with PL/SQL * You can use numeric, character, and string literals as bind arguments * You cannot use bind arguments to pass the names of schema objects to a dynamic SQL statement. does this mean you can't dynamically sub in a variable for a table name? if so, why keep that limitation? one of the main reasons to use dynamic sql is for schema objects. No, it doesn't mean. You can create any SQL statement. Only you cannot use binding (USING clause) for table name. Why? Because it's based on prepared statements, and there you cannot use parameters for column's or table's names. You can: .. execute 'select * from || table || ' where a = $1' using var_a .. Older patch was based on strings, and it was really ugly and without any effects for security. Usually You have more params than table names, so this limit is not too much hard. Now, patch is simple, because there isn't any redundance. Main reason for this patch is security. Not comfort for programmer. But I belive, so it's good step forward. Pavel p.s. I though about it, and this is more consistent. You have only one rule for params everywhere. ~ never use params as object names. ---(end of broadcast)--- TIP 1: 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] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
From: Dave Page [EMAIL PROTECTED] Hiroshi Saito wrote: Hi. Second, it is big problem http://winpg.jp/~saito/pg83/pg83b1-err2.txt It is text serch config error. However, It passes initdb.(locale=Japanese_Japan.932 ... This is ShiftJIS locale) And a test continues The changes that were made were only to re-enable UTF-8. Yes, Please see, http://winpg.jp/~saito/pg83/pg83b1-err2.txt Is that initdb is successful a problem as for this? SJIS wasn't ever supported as a server encoding (http://www.postgresql.org/docs/8.2/interactive/multibyte.html). The fact that initdb continues if you use Japanese_Japan.932 is an inconsistency I reported previously but has yet to be fixed. Yes, However, Encoding and locale are not equivalent. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
Hiroshi Saito wrote: From: Dave Page [EMAIL PROTECTED] Hiroshi Saito wrote: Hi. Second, it is big problem http://winpg.jp/~saito/pg83/pg83b1-err2.txt It is text serch config error. However, It passes initdb.(locale=Japanese_Japan.932 ... This is ShiftJIS locale) And a test continues The changes that were made were only to re-enable UTF-8. Yes, Please see, http://winpg.jp/~saito/pg83/pg83b1-err2.txt Is that initdb is successful a problem as for this? Oh, sorry - misread that. I chatted with Magnus about that. It is correct, but misleading. pg_control will say Japanese_Japan.932 as well iirc, even though it is really Japanese_Japan.65001. Regards, Dave ---(end of broadcast)--- TIP 1: 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] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
Dave Page wrote: Hiroshi Saito wrote: Hi. Second, it is big problem http://winpg.jp/~saito/pg83/pg83b1-err2.txt It is text serch config error. However, It passes initdb.(locale=Japanese_Japan.932 ... This is ShiftJIS locale) And a test continues The changes that were made were only to re-enable UTF-8. SJIS wasn't ever supported as a server encoding (http://www.postgresql.org/docs/8.2/interactive/multibyte.html). The fact that initdb continues if you use Japanese_Japan.932 is an inconsistency I reported previously but has yet to be fixed. That is a good point, if unrelated to this very discussion. Do we want to change that thing to an exit instead of complain-and-continue? I think yes? //Magnus ---(end of broadcast)--- TIP 1: 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] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
Dave Page wrote: Hiroshi Saito wrote: From: Dave Page [EMAIL PROTECTED] Hiroshi Saito wrote: Hi. Second, it is big problem http://winpg.jp/~saito/pg83/pg83b1-err2.txt It is text serch config error. However, It passes initdb.(locale=Japanese_Japan.932 ... This is ShiftJIS locale) And a test continues The changes that were made were only to re-enable UTF-8. Yes, Please see, http://winpg.jp/~saito/pg83/pg83b1-err2.txt Is that initdb is successful a problem as for this? Oh, sorry - misread that. I chatted with Magnus about that. It is correct, but misleading. pg_control will say Japanese_Japan.932 as well iirc, even though it is really Japanese_Japan.65001. Not so. The locale is Japanese_Japan, really. That's the only part that's relevant for UTF16 encodings, which is what we use to do UTF8. We specifically *don't* try to use Japanese_Japan.65001. //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
Hi. From: Dave Page [EMAIL PROTECTED] Yes, Please see, http://winpg.jp/~saito/pg83/pg83b1-err2.txt Is that initdb is successful a problem as for this? Oh, sorry - misread that. I chatted with Magnus about that. It is correct, but misleading. pg_control will say Japanese_Japan.932 as well iirc, even though it is really Japanese_Japan.65001. But, Please see. http://winpg.jp/~saito/pg83/pg83b1-err3.txt Japanese_Japan.65001 is error... Japanese_Japan is true. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
Magnus Hagander wrote: Not so. The locale is Japanese_Japan, really. That's the only part that's relevant for UTF16 encodings, which is what we use to do UTF8. We specifically *don't* try to use Japanese_Japan.65001. Thats not what I mean. From a *usability* perspective, Hiroshi should see Japanese_Japan.65001 because he's selected UTF-8 in Japanese_Japan. He shouldn't see Japanese_Japan.932 because that definitely isn't what he selected. /D ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
Hiroshi Saito wrote: Hi. From: Dave Page [EMAIL PROTECTED] Yes, Please see, http://winpg.jp/~saito/pg83/pg83b1-err2.txt Is that initdb is successful a problem as for this? Oh, sorry - misread that. I chatted with Magnus about that. It is correct, but misleading. pg_control will say Japanese_Japan.932 as well iirc, even though it is really Japanese_Japan.65001. But, Please see. http://winpg.jp/~saito/pg83/pg83b1-err3.txt Japanese_Japan.65001 is error... Japanese_Japan is true. Yes, that is expected. If you explicitly ask for the .65001 locale it will try the one that doesn't have the proper NLS files, and that shouldn't work. If you just put in Japanese_Japan, it will use the UTF16 locale. //Magnus ---(end of broadcast)--- TIP 1: 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] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
But, Please see. http://winpg.jp/~saito/pg83/pg83b1-err3.txt Japanese_Japan.65001 is error... Japanese_Japan is true. However, The test of this state is continued. But but but, Sorry, I face to a bed... Regards, Hiroshi Saito ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
Dave Page wrote: Magnus Hagander wrote: Not so. The locale is Japanese_Japan, really. That's the only part that's relevant for UTF16 encodings, which is what we use to do UTF8. We specifically *don't* try to use Japanese_Japan.65001. Thats not what I mean. From a *usability* perspective, Hiroshi should see Japanese_Japan.65001 because he's selected UTF-8 in Japanese_Japan. He shouldn't see Japanese_Japan.932 because that definitely isn't what he selected. I'l grant you that from a usbility perspective, he should see Japanese_Japan. Not the .65001 part, though. //Magnus ---(end of broadcast)--- TIP 1: 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] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
Hiroshi Saito wrote: Hi. From: Dave Page [EMAIL PROTECTED] Yes, Please see, http://winpg.jp/~saito/pg83/pg83b1-err2.txt Is that initdb is successful a problem as for this? Oh, sorry - misread that. I chatted with Magnus about that. It is correct, but misleading. pg_control will say Japanese_Japan.932 as well iirc, even though it is really Japanese_Japan.65001. But, Please see. http://winpg.jp/~saito/pg83/pg83b1-err3.txt Japanese_Japan.65001 is error... Japanese_Japan is true. Yes, we're faking utf-8 support using utf-16. Specifying it as you have there bypasses the workaround and tries to use the 65001 codepage which then fails because LC_CTYPE cannot be set to .65001 in any locale. /D ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
Magnus Hagander wrote: Dave Page wrote: Magnus Hagander wrote: Not so. The locale is Japanese_Japan, really. That's the only part that's relevant for UTF16 encodings, which is what we use to do UTF8. We specifically *don't* try to use Japanese_Japan.65001. Thats not what I mean. From a *usability* perspective, Hiroshi should see Japanese_Japan.65001 because he's selected UTF-8 in Japanese_Japan. He shouldn't see Japanese_Japan.932 because that definitely isn't what he selected. I'l grant you that from a usbility perspective, he should see Japanese_Japan. Not the .65001 part, though. Well, that depends on whether we care that we're actually faking the utf-8 support and/or we want to keep the message consistent with what you'd see in other locales. /D ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
2007/10/16, Hiroshi Saito [EMAIL PROTECTED]: Hi. I can test it with czech locale. Can I download binaries anywhere? http://winpg.jp/~saito/pg83/postgresql-8.3beta-cvs.tgz It is a thing after regression test.(MinGW+gcc) I have problem, there isn't libintl-2.dll Pavel ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
Magnus Hagander [EMAIL PROTECTED] writes: Dave Page wrote: SJIS wasn't ever supported as a server encoding (http://www.postgresql.org/docs/8.2/interactive/multibyte.html). The fact that initdb continues if you use Japanese_Japan.932 is an inconsistency I reported previously but has yet to be fixed. That is a good point, if unrelated to this very discussion. Do we want to change that thing to an exit instead of complain-and-continue? I think yes? Yeah, I thought we'd agreed to that a few days ago. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Proposal: PL/pgSQL EXECUTE INTO USING (for 8.4)
On 10/17/07, Pavel Stehule [EMAIL PROTECTED] wrote: New syntax: a) EXECUTE stringexpr [INTO [STRICT] varlist [USING exprlist] b) FOR varlist IN EXECUTE stringexpr USING exprlist LOOP Just chiming in with a +1. I would find this feature very useful. Substitution of parameters is way more elegant than quoting, and the syntax looks nice. Regards, BJ ---(end of broadcast)--- TIP 1: 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] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
Hi. From: Pavel Stehule [EMAIL PROTECTED] I can test it with czech locale. Can I download binaries anywhere? http://winpg.jp/~saito/pg83/postgresql-8.3beta-cvs.tgz It is a thing after regression test.(MinGW+gcc) I have problem, there isn't libintl-2.dll Ooops, sorry, it is full-build. Please, this is minimum composition http://winpg.jp/~saito/pg83/postgresql-8.3beta-cvs-minbin.tgz Thanks. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: Re-allow UTF8 encodings on win32.
Hi. From: Magnus Hagander [EMAIL PROTECTED] But, Please see. http://winpg.jp/~saito/pg83/pg83b1-err3.txt Japanese_Japan.65001 is error... Japanese_Japan is true. Yes, that is expected. If you explicitly ask for the .65001 locale it will try the one that doesn't have the proper NLS files, and that shouldn't work. If you just put in Japanese_Japan, it will use the UTF16 locale. Umm, As for result ... initdb -E UTF8 --locale=Japanese_Japan -D../data http://winpg.jp/~saito/pg83/pg83b1-err4.txt It seems that it is only complemented. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
