Tom Lane wrote:
* ISTM that the patch is designed on the plan that the PD_ALL_VISIBLE
page header flag *must* be correct, but it's really okay if the backing
map bit *isn't* correct --- in particular we don't trust the map bit
when performing antiwraparound vacuums. This isn't well documented.
Tom Lane napsal(a):
What seems to have happened is that the bgwriter didn't get as far as
the first line of BackgroundWriterMain before the client backend tried
to issue a checkpoint request.
This is obviously a pretty minor issue, but it still seems worth fixing.
We could either try to make
Jim Cox wrote:
A patch s/b attached which adds a VERBOSE option to the CLUSTER command as
mentioned in the following TODO item for CLUSTER: Add VERBOSE option
to report tables as they are processed, like VACUUM VERBOSE.
I have committed this version of your patch, but moving the VERBOSE
Hi,
recently, I wrote a really complex SELECT statement which consists of about
20 relations using NATURAL JOIN method and every single relation consists 50
columns. It looks like:
PREPARE ugly_stmt AS
SELECT * FROM t1 NATURAL JOIN t2 NATURAL JOIN t3 ... NATURAL JOIN t20 WHERE
id = $1;
All
Pavel Stehule wrote:
I have problem with sending patch, so I am send link
http://www.pgsql.cz/patches/defaults.diff.gz
Example:
postgres=# create function fx(a int, b int default 30, c int default 40)
Could you explain why you store the default expressions in a new posexpr
type rather than
2008/11/24 Peter Eisentraut [EMAIL PROTECTED]:
Pavel Stehule wrote:
I have problem with sending patch, so I am send link
http://www.pgsql.cz/patches/defaults.diff.gz
Example:
postgres=# create function fx(a int, b int default 30, c int default 40)
Could you explain why you store the
Zdenek Kotala napsal(a):
Tom Lane napsal(a):
What seems to have happened is that the bgwriter didn't get as far as
the first line of BackgroundWriterMain before the client backend tried
to issue a checkpoint request.
This is obviously a pretty minor issue, but it still seems worth fixing.
We
Hi Stehule,
I have looked at the patch and it looks great. Here are my observation
Compilation
1 - Patch applied successfully on CVS-HEAD
2 - No compilation error found
Code
---
1 - Style of code is very close to the existing PG code.
2 - Comments look OK to me.
3 - I
I hope this is the right place to report a bug/issue in the official
documentation...
In
http://www.postgresql.org/docs/current/interactive/plpgsql-control-structures.html
there is an example for a function, cs_refresh_mviews(), chapter 38.6.4.
Within this function there are a PERFORM
Hello,
thank you, for you review. Grouping Sets is nice feature, but this
patch patch has some issues, and I don't expect commiting into 8.4. I
sent it, because it is interaction with window function's patch and
(maybe) some code should be shared - and this information should be
usefull for other
Hitoshi Harada wrote:
2008/11/20 David Rowley [EMAIL PROTECTED]:
I won't be around until Monday evening (Tuesday morning JST). I'll pickup
the review again there. It's really time for me to push on with this review.
The patch is getting closer to getting the thumbs up from me. I'm really
hoping
Tom Lane wrote:
I'd suggest making the callers do something like
#ifdef HAVE_FNMATCH
#include fnmatch.h
#else
#include port/pg_fnmatch.h
#endif
The way Autoconf suggests to organize this is to provide a fake
fnmatch.h (they call it fnmatch_.h) and link
Tom Lane wrote:
Also, right now we have got
src/include/getaddrinfo.h
src/include/getopt_long.h
which really make me itch now that I am contemplating the possibility
that we try to use libc-supplied code for these functions along with
our own header definitions.
These particular header files
On Mon, Nov 24, 2008 at 6:02 AM, A. Kretschmer
[EMAIL PROTECTED] wrote:
I hope this is the right place to report a bug/issue in the official
documentation...
In
http://www.postgresql.org/docs/current/interactive/plpgsql-control-structures.html
there is an example for a function,
Peter Eisentraut wrote:
Tom Lane wrote:
I think the reason we've avoided putting such stuff into include/port/
is that right now that directory consists exclusively of OS-specific
files. Maybe we need another include subdirectory?
I think the idea is rather that you don't need to change
Hiroshi Inoue wrote:
Hi Magnus and all,
Magnus Hagander wrote:
Log Message:
---
Explicitly bind gettext() to the UTF8 locale when in use.
This is required on Windows due to the special locale
handling for UTF8 that doesn't change the full environment.
Thanks to this change
I updated the patch set of SE-PostgreSQL (revision 1244).
[1/6]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1244.patch
[2/6]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1244.patch
[3/6]
The way I read this patch we do:
1) Get the time in CP_ACP
2) Convert to UTF16
3) Convert to UTF8
4) If necessary, convert to the charset in the database
We could be more efficient by at least folding 1 and 2 into a single
step, which means getting it in UTF16 from the beginning. How about
Bruce Momjian wrote:
KaiGai Kohei wrote:
What I am saying is for the default compile, SQL-level ACLs should be
possible because, since the ACL field has optional storage, there is no
downside to have it be available by default.
I think it is a possible and desirable desicion from the viewpoint
am Mon, dem 24.11.2008, um 7:24:47 -0500 mailte Merlin Moncure folgendes:
On Mon, Nov 24, 2008 at 6:02 AM, A. Kretschmer
[EMAIL PROTECTED] wrote:
I hope this is the right place to report a bug/issue in the official
documentation...
In
Pavel Stehule [EMAIL PROTECTED] writes:
2008/11/24 Peter Eisentraut [EMAIL PROTECTED]:
Could you explain why you store the default expressions in a new posexpr
type rather than in an array of text (compare pg_attrdef.adbin)?
I would to implement named params - and there expressions, that are
Zdenek Kotala [EMAIL PROTECTED] writes:
Zdenek Kotala napsal(a):
By my opinion there is not reason to retry kill call, because it fails
only in situation if process does not exist or caller does not have
permission to send a signal.
If I think more about it, that code is here because it
2008/11/24 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
2008/11/24 Peter Eisentraut [EMAIL PROTECTED]:
Could you explain why you store the default expressions in a new posexpr
type rather than in an array of text (compare pg_attrdef.adbin)?
I would to implement named
A. Kretschmer wrote:
Okay, it is an argument. On the other side, it was a question today in
the irc-channel (#postgresql) today, someone asked, why his funktion
don't work. I think, such examples should not contain such code. It is
not apparent that this function are not available.
Perhaps
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
Zdenek Kotala napsal(a):
By my opinion there is not reason to retry kill call, because it fails
only in situation if process does not exist or caller does not have
permission to send a signal.
If I think more about it, that code is
2008/11/24 Heikki Linnakangas [EMAIL PROTECTED]:
Hitoshi Harada wrote:
2008/11/20 David Rowley [EMAIL PROTECTED]:
I won't be around until Monday evening (Tuesday morning JST). I'll pickup
the review again there. It's really time for me to push on with this
review.
The patch is getting
Pavan Deolasee escribió:
Following test case gives a warning of snapshot not destroyed at commit
time.
CREATE TABLE test (a int);
INSERT INTO test VALUES (1);
BEGIN;
DECLARE c CURSOR FOR SELECT * FROM test FOR update;
SAVEPOINT A;
FETCH -2 FROM c;
ROLLBACK TO SAVEPOINT A;
COMMIT;
Dave Page wrote:
On Mon, Nov 24, 2008 at 1:38 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
A. Kretschmer wrote:
Okay, it is an argument. On the other side, it was a question today in
the irc-channel (#postgresql) today, someone asked, why his funktion
don't work. I think, such
am Mon, dem 24.11.2008, um 13:47:54 + mailte Dave Page folgendes:
On Mon, Nov 24, 2008 at 1:38 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
A. Kretschmer wrote:
Okay, it is an argument. On the other side, it was a question today in
the irc-channel (#postgresql) today, someone asked,
On Mon, Nov 24, 2008 at 1:53 PM, Andrew Dunstan [EMAIL PROTECTED] wrote:
It might also be useful to create such a database at initdb time so
newbies have something interesting to look at right away.
No, there is no need to clutter every installation in the world with such a
database. You
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Hi Magnus and all,
Magnus Hagander wrote:
Log Message:
---
Explicitly bind gettext() to the UTF8 locale when in use.
This is required on Windows due to the special locale
handling for UTF8 that doesn't change the full environment.
Dave Page wrote:
On Mon, Nov 24, 2008 at 1:53 PM, Andrew Dunstan [EMAIL PROTECTED] wrote:
It might also be useful to create such a database at initdb time so
newbies have something interesting to look at right away.
No, there is no need to clutter every installation in the world with such a
Andrew Dunstan [EMAIL PROTECTED] writes:
Dave Page wrote:
It might also be useful to create such a database at initdb time so
newbies have something interesting to look at right away.
No, there is no need to clutter every installation in the world with
such a database. You could make it an
On Mon, Nov 24, 2008 at 2:02 PM, Tom Lane [EMAIL PROTECTED] wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Dave Page wrote:
It might also be useful to create such a database at initdb time so
newbies have something interesting to look at right away.
No, there is no need to clutter every
Hiroshi Inoue wrote:
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Hi Magnus and all,
Magnus Hagander wrote:
Log Message:
---
Explicitly bind gettext() to the UTF8 locale when in use.
This is required on Windows due to the special locale
handling for UTF8 that doesn't change the
On Mon, Nov 24, 2008 at 2:01 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Dave Page wrote:
That would defeat the point. Not that I have any great feelings either
way, but fwiw, Microsoft and Oracle both create a sample database
iirc.
Last I checked, MS did it optionally only, no?
Yes, but
Martin Pihlak wrote:
Here's another revision of the connection manager. This adds:
* reference documentation
* psql, tab-completion, \dw, \dr, \dm commands.
* pg_dump support
Still todo:
* more comprehensive regression tests
* introductory documentation
* dblink support
I hope to finish
Dave Page [EMAIL PROTECTED] writes:
On Mon, Nov 24, 2008 at 1:53 PM, Andrew Dunstan [EMAIL PROTECTED] wrote:
No, there is no need to clutter every installation in the world with such a
database. You could make it an addon module, or a pgfoundry project.
That would defeat the point.
By that
On Mon, Nov 24, 2008 at 2:14 PM, Tom Lane [EMAIL PROTECTED] wrote:
Dave Page [EMAIL PROTECTED] writes:
On Mon, Nov 24, 2008 at 1:53 PM, Andrew Dunstan [EMAIL PROTECTED] wrote:
No, there is no need to clutter every installation in the world with such a
database. You could make it an addon
am Mon, dem 24.11.2008, um 9:02:37 -0500 mailte Tom Lane folgendes:
Andrew Dunstan [EMAIL PROTECTED] writes:
Dave Page wrote:
It might also be useful to create such a database at initdb time so
newbies have something interesting to look at right away.
No, there is no need to clutter
On Mon, Nov 24, 2008 at 9:02 AM, Tom Lane [EMAIL PROTECTED] wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Dave Page wrote:
It might also be useful to create such a database at initdb time so
newbies have something interesting to look at right away.
No, there is no need to clutter every
Heikki Linnakangas [EMAIL PROTECTED] writes:
I've been thinking that we could add one frozenxid field to each
visibility map page, for the oldest xid on the heap pages covered by the
visibility map page. That would allow more fine-grained anti-wraparound
vacuums as well.
This doesn't
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
... The other option is to have
autoconf substitute our own local version of fnmatch when this happens.
How would one go about to do that in autoconf asks the autoconf n00b?
I'd try adding a little test program
Magnus Hagander wrote:
Anything that needs symlinks will need a set of workarounds on Windows,
having us manually do a copy of the files. We already do this in a
couple of cases, but relying more on it would make things even more
kludgy I think...
Autoconf automatically uses cp if ln doesn't
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
So it seems like we do indeed want to rejigger autovac's rules a bit
to account for the possibility of wanting to apply vacuum to get
visibility bits set.
I'm not too excited about triggering an extra vacuum. As Matthew pointed
Peter Eisentraut wrote:
Magnus Hagander wrote:
Anything that needs symlinks will need a set of workarounds on Windows,
having us manually do a copy of the files. We already do this in a
couple of cases, but relying more on it would make things even more
kludgy I think...
Autoconf
Hi Magnus-san.
Um, Though regrettable, it is not in a good state.
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/Mugnus-patch.png
- Original Message -
From: Magnus Hagander [EMAIL PROTECTED]
The way I read this patch we do:
1) Get the time in CP_ACP
2) Convert
Magnus Hagander [EMAIL PROTECTED] writes:
*** a/src/backend/utils/adt/pg_locale.c
--- b/src/backend/utils/adt/pg_locale.c
***
*** 54,59
--- 54,60
#include utils/memutils.h
#include utils/pg_locale.h
+ #include mb/pg_wchar.h
#define
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
*** a/src/backend/utils/adt/pg_locale.c
--- b/src/backend/utils/adt/pg_locale.c
***
*** 54,59
--- 54,60
#include utils/memutils.h
#include utils/pg_locale.h
+ #include mb/pg_wchar.h
#define
Does it work when you're not using C-locale? This looks like the
codepath Tom pointed out was wrong.
//Magnus
Hiroshi Saito wrote:
Hi Magnus-san.
Um, Though regrettable, it is not in a good state.
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/Mugnus-patch.png
Peter Eisentraut wrote:
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
... The other option is to have
autoconf substitute our own local version of fnmatch when this happens.
How would one go about to do that in autoconf asks the autoconf n00b?
I'd try
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
*** a/src/backend/utils/adt/pg_locale.c
--- b/src/backend/utils/adt/pg_locale.c
***
*** 54,59
--- 54,60
#include utils/memutils.h
#include utils/pg_locale.h
+ #include
It was brought to my attention that DISCARD ALL
does not release advisory locks:
http://pgfoundry.org/tracker/index.php?func=detailaid=1010499group_id=1000258atid=983
Thus connection managers / poolers need to do that manually.
This obviously means DISCARD ALL needs fixing. Applied
patch
Marko Kreen [EMAIL PROTECTED] writes:
It was brought to my attention that DISCARD ALL
does not release advisory locks:
What is the argument that it should?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Peter Eisentraut [EMAIL PROTECTED] writes:
Well, FNM_CASEFOLD is not POSIX, and Autoconf thinks it's a GNU
extension, which has obviously crept into other systems. So you'd need
to use AC_FUNC_FNMATCH_GNU, but that also requires you to use the GNU
replacement implementation. (A bit
Hi Magnus-san.
Umm, format operand seems to be a wide character sequence.
- Original Message -
From: Magnus Hagander [EMAIL PROTECTED]
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
*** a/src/backend/utils/adt/pg_locale.c
---
Tom Lane [EMAIL PROTECTED] writes:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I've been thinking that we could add one frozenxid field to each
visibility map page, for the oldest xid on the heap pages covered by the
visibility map page. That would allow more fine-grained anti-wraparound
On 11/24/08, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
It was brought to my attention that DISCARD ALL
does not release advisory locks:
What is the argument that it should?
DISCARD ALL is supposed to be used by poolers to reset connection
back to startup
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Please stick to the convention of including include files in
alphabetical order.
I didn't realize we had such a convention. Is this for all include files or
only within a directory? Are there exceptions where the
Gregory Stark wrote:
However I'm a bit puzzled how you could possibly maintain this frozenxid. As
soon as you freeze an xid you'll have to visit all the other pages covered by
that visibility map page to see what the new value should be.
Right, you could only advance it when you scan all the
Tom Lane wrote:
KaiGai Kohei [EMAIL PROTECTED] writes:
However, I think we have a few issues, and it makes unclear whether
we can make an agreement in the community.
The one is a cost of security hooks. They consume a bit more CPU steps
when a security mechanism is enabled. The other is
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
I'm a tad worried about what happens when the values that are
frequently
occurring in the outer relation are also frequently occurring in the
inner (which hardly seems an improbable case). Don't you stand a
severe
risk of
Heikki Linnakangas [EMAIL PROTECTED] writes:
Gregory Stark wrote:
However I'm a bit puzzled how you could possibly maintain this frozenxid. As
soon as you freeze an xid you'll have to visit all the other pages covered by
that visibility map page to see what the new value should be.
Right,
Magnus Hagander [EMAIL PROTECTED] writes:
Hiroshi Inoue wrote:
because Shift_JIS isn't allowed as a server encoding. So
the Japanese Windows native message encoding Shift_JIS never
matches the server encoding EUC_JP and a conversion between
Shitt_jis and EUC_JP is necessarily needed.
Ah, so
On Mon, Nov 24, 2008 at 1:38 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
A. Kretschmer wrote:
Okay, it is an argument. On the other side, it was a question today in
the irc-channel (#postgresql) today, someone asked, why his funktion
don't work. I think, such examples should not contain such
On Monday 24 November 2008 16:07:49 Dave Page wrote:
That's the point of having a sample database ready to play with. The
docs needn't have clutter, but the user can try out any of the
examples without needing to setup anything first. It's a simple
usability tweak that can help ease the
Tom Lane escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
Pavan Deolasee escribi�:
Should we call FreeQueryDesc() even for failed portals in PortalCleanup() ?
Or PortalDrop() is a better(right) place to do that ?
That doesn't work; doing it causes a crash:
I think the fundamental
Clutter is the problem. The cs_log functions in the example do not
serve any purpose that is helpful to describe a for loop. They serve
no real purpose...why not 'raise notice' or just remove them? It
should be clear to distinguish from real and non-real elements.
+1 for RAISE NOTICE.
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane escribió:
I think the fundamental bug here is that you tried to skip using the
ResourceOwner mechanism for snapshot references. That's basically
not gonna work.
Right :-( I'll see how to go about this.
It strikes me that you might be able
Tom Lane [EMAIL PROTECTED] writes:
Please stick to the convention of including include files in
alphabetical order.
I didn't realize we had such a convention. Is this for all include files or
only within a directory? Are there exceptions where the order matters or have
we managed to make sure
Gregory Stark [EMAIL PROTECTED] writes:
So if it's possible for the frozenxid in the visibility map to go backwards
then it's no good, since if that update is lost we might skip a necessary
vacuum freeze.
Seems like a lost disk write would be enough to make that happen.
Now you might argue
Alvaro Herrera [EMAIL PROTECTED] writes:
Pavan Deolasee escribió:
Should we call FreeQueryDesc() even for failed portals in PortalCleanup() ?
Or PortalDrop() is a better(right) place to do that ?
That doesn't work; doing it causes a crash:
I think the fundamental bug here is that you tried
Sam Mason [EMAIL PROTECTED] writes:
On Mon, Nov 24, 2008 at 10:45:42AM -0500, Tom Lane wrote:
Well, I can't reproduce that here. Something strange about your
configuration maybe?
Not that I know of. I've just created a test cluster to make sure and I
get the same behaviour.
Hmm ... the
On Mon, Nov 24, 2008 at 02:46:45PM -0500, Tom Lane wrote:
What it boils down to is lack of error checking in psql (not the
backend). Specifically, we fail to enlarge the output buffer for
psqlscan.l, which causes appendBinaryPQExpBuffer to silently not insert
the chunk it's currently being
On Monday 24 November 2008 11:40:31 Pavel Stehule wrote:
I would to implement named params - and there expressions, that are
used as default params, should not be continual. I don't store params
as array of text because I would to eliminate repeated expression's
parsing. So I use similar
On Monday 24 November 2008 16:55:17 Magnus Hagander wrote:
Then again, having looked into the libpq source now, is using fnmatch()
even appropriate here? The matching rules for https are in RFC 2818:
Using fnmatch(), however, will also treat ? and [] special and it will
not follow the
Pavel Stehule escribió:
2008/11/24 Tom Lane [EMAIL PROTECTED]:
Say again? The representation Peter is suggesting *is* what is used
in rules and views. If you've re-invented that wheel, undo it.
Then I am blind. I store serialised transformed expression, but if
better solution exists,
I wrote:
Some more information on this:
https://www.switch.ch/pki/meetings/2007-01/namebased_ssl_virtualhosts.pdf
slide 5 lists the matching rules for email, HTTP, and LDAP over TLS,
respectively, which are not all the same. Also note that these methods
have rules for interpreting fields in
2008/11/24 Peter Eisentraut [EMAIL PROTECTED]:
On Monday 24 November 2008 11:40:31 Pavel Stehule wrote:
I would to implement named params - and there expressions, that are
used as default params, should not be continual. I don't store params
as array of text because I would to eliminate
On Monday 24 November 2008 23:21:15 Pavel Stehule wrote:
You mean you want to avoid repeated parsing of expressions in case the
same expression is used as a default value for several parameters? How
common would that be?
no - I am reading default parameters in call statement parsing.
2008/11/24 Peter Eisentraut [EMAIL PROTECTED]:
On Monday 24 November 2008 23:21:15 Pavel Stehule wrote:
You mean you want to avoid repeated parsing of expressions in case the
same expression is used as a default value for several parameters? How
common would that be?
no - I am reading
Heikki,
The following test fails with your patch on my system. Could you check
if you can reproduce?
psql (8.4devel)
Type help for help.
test=# begin;
BEGIN
test=# create table paul(x int);
CREATE TABLE
test=# insert into paul values(1);
INSERT 0 1
test=# prepare transaction
Peter Eisentraut [EMAIL PROTECTED] writes:
On Monday 24 November 2008 23:21:15 Pavel Stehule wrote:
Default parameters are implemented similar to variadic functions - so
no changes on PL part - all changes are on caller part.
Then I don't understand why you need this special data type instead
On Monday 24 November 2008 09:10:29 Dave Page wrote:
On Mon, Nov 24, 2008 at 2:01 PM, Magnus Hagander [EMAIL PROTECTED]
wrote:
Dave Page wrote:
That would defeat the point. Not that I have any great feelings either
way, but fwiw, Microsoft and Oracle both create a sample database
iirc.
Fujii Masao [EMAIL PROTECTED] wrote:
On Fri, Nov 14, 2008 at 7:15 PM, Fujii Masao [EMAIL PROTECTED] wrote:
Attached is the latest version of Synch Rep patch. Sorry for my late
posting.
I fixed some bugs in v1patch and integrated walreceiver into core.
I have some comments about v3 patch.
Tao Ma [EMAIL PROTECTED] writes:
recently, I wrote a really complex SELECT statement which consists of about
20 relations using NATURAL JOIN method and every single relation consists 50
columns. It looks like:
Maybe you should rethink your schema design...
It seems Postgres cost lots of
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Hiroshi Inoue wrote:
because Shift_JIS isn't allowed as a server encoding. So
the Japanese Windows native message encoding Shift_JIS never
matches the server encoding EUC_JP and a conversion between
Shitt_jis and EUC_JP is necessarily
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm not following this either. If the patch is really necessary then it
seems it must be working around a bug in the Windows version of gettext,
ie failure to distinguish CP932 from CP20932. Is that correct?
I'm afraid I don't
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm not following this either. If the patch is really necessary then it
seems it must be working around a bug in the Windows version of gettext,
ie failure to distinguish CP932 from CP20932. Is that correct?
I'm
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
If that's true then this code is presently broken for *every* locale
under Windows, not only Japanese.
Maybe there are a few languages/countires where 2 encodings are
widely used.
UTF8 vs Latin-N? In any case I think the problem is
2008/11/25 Heikki Linnakangas [EMAIL PROTECTED]:
Hitoshi Harada wrote:
If you keep this in your mind, please don't be annoyed but the current
frame concept is wrong.
...
Note that on empno=4 then last_value=4(yours)/3(mine), which means the
frame is applied to last_value() as well as
2008/11/25 Tom Lane [EMAIL PROTECTED]:
Peter Eisentraut [EMAIL PROTECTED] writes:
On Monday 24 November 2008 23:21:15 Pavel Stehule wrote:
Default parameters are implemented similar to variadic functions - so
no changes on PL part - all changes are on caller part.
Then I don't understand why
On 25 nov 2008, at 05.00, Tom Lane [EMAIL PROTECTED] wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Tom Lane wrote:
If that's true then this code is presently broken for *every* locale
under Windows, not only Japanese.
Maybe there are a few languages/countires where 2 encodings are
widely
On Sat, Nov 22, 2008 at 6:28 PM, Simon Riggs [EMAIL PROTECTED] wrote:
My worry is that there has not been an exhaustive analysis. Almost
correct and probably correct is not the same thing as correct. We
need to look through all of the changes that occur at the end of
recovery to be certain we
94 matches
Mail list logo
