On Sat, Mar 24, 2007 at 09:37:07PM +, Gregory Stark wrote:
It sounds like a fine idea from the point of view of flexibility. But as far
as faster... I guess it depends on how often HeapTupleSatisfiesVisibility is
used in contexts where the compiler is able to optimize away the conditionals
Martijn van Oosterhout kleptog@svana.org writes:
On Sat, Mar 24, 2007 at 09:37:07PM +, Gregory Stark wrote:
It sounds like a fine idea from the point of view of flexibility. But as far
as faster... I guess it depends on how often HeapTupleSatisfiesVisibility is
used in contexts where the
Tatsuo Ishii [EMAIL PROTECTED] writes:
I'm confused. If this is exactly the same as EUC_JP, why do we need
any new code at all?
I said *encoding schema is same, not the contents (character set) is
same. In another word, characters included in EUC_JP are not same as
On Sat, Mar 24, 2007 at 11:28:26PM -0400, Alvaro Herrera wrote:
Bruce Momjian wrote:
I have emailed Andrew Yu to see if we can remove his line, but I
question whether the other people can be reached.
How should we handle this?
If they are released under the BSD license, why do we care
Gregory Stark [EMAIL PROTECTED] writes:
It sounds like a fine idea from the point of view of flexibility. But as far
as faster... I guess it depends on how often HeapTupleSatisfiesVisibility is
used in contexts where the compiler is able to optimize away the conditionals
or the cpu is able to
Jim Nasby [EMAIL PROTECTED] writes:
On Mar 21, 2007, at 5:11 AM, Tom Lane wrote:
constraint_exclusion
Hrm... wasn't that option added in case there was a bug in the
exclusion code?
Well, the bug was a lack of ways to get rid of plans that were
no longer valid because of constraint changes;
Neil Conway [EMAIL PROTECTED] writes:
Rather than removing the copyright clause per se, it might be better to
just update to the latest versions of these files in an upstream source
(e.g. NetBSD). They've already gone through their source tree and
updated the Berkeley copyrights as
Ühel kenal päeval, R, 2007-03-23 kell 06:10, kirjutas Andrew -
Supernews:
On 2007-03-23, ITAGAKI Takahiro [EMAIL PROTECTED] wrote:
Thanks, it all made sense to me. My proposal was completely wrong.
Actually, I think your proposal is fundamentally correct, merely incomplete.
Doing
stark [EMAIL PROTECTED] writes:
postgres=# show datestyle;
DateStyle
---
ISO, DMY
(1 row)
postgres=# set datestyle='DMY,ISO';
SET
postgres=# show datestyle;
DateStyle
---
ISO, DMY
(1 row)
What's your point?
regards, tom lane
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hm, you're right. This arises from the fact that _SPI_execute_plan
rejects cursor-related utility statements. While I'd never stopped
to question that before, it does seem like this restriction is a
bit pointless. Does anyone remember
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
It sounds like a fine idea from the point of view of flexibility. But as far
as faster... I guess it depends on how often HeapTupleSatisfiesVisibility is
used in contexts where the compiler is able to optimize away
Gregory Stark [EMAIL PROTECTED] writes:
That's not really the point. The problem is that the compiler usually can't
deduce which function you're calling or even which set of functions you might
be calling. So, for example, the compiler will have trouble determining which
variables may be
Tom Lane [EMAIL PROTECTED] writes:
What's your point?
Apparently my point is that I should have checked the docs before assuming I
understood how this variable worked. I guess I've never needed to touch it
before.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
I wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Again though, I really don't think it matters.
Agreed, it's unlikely this would be a significant change either way.
Just for the record, pgbench numbers seem unaffected by this patch
(on Fedora Core 6 x86_64).
regards,
I wrote:
I'd venture that we should try to get rid of the restriction, but I'm
unsure whether removing the error check is sufficient or whether there
are real problems it's preventing.
I did a little experimentation and it seems that DECLARE CURSOR,
FETCH, and CLOSE work perfectly fine when
Magnus Hagander [EMAIL PROTECTED] writes:
tsearch2 regression tests are also failing on win32/msvc, with attached
diffs.
Any pointers on where to start? ;)
FWIW, it looks like it failed to reject stopwords. Is it possible you
ran it in an environment that would make it pick the Russian
I wrote:
I'd like to take the TODO item that reads, Add support for arrays of
complex types, but before I start patching, I'd like to see whether
what I'm about to do makes any sense:
I've written up a patch intended to implement this on the
non-pg_catalog tables and VIEWs, but while it
Hello,
PostgreSQL suppots SJIS, BIG5, GBK, UHC and GB18030 as client encodings,
but we cannot use them as server encodings. Are there any reason for it?
AFAICS, we can support them only if we add each pg_xxx2wchar_with_len().
I'd like to add server-side SJIS supports for Windows Japanese
David Fetter [EMAIL PROTECTED] writes:
I've written up a patch intended to implement this on the
non-pg_catalog tables and VIEWs, but while it builds, it doesn't
initdb. Enclosed are the patch and the error log.
Any hints as to what I might look at?
creating template1 database in
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
PostgreSQL suppots SJIS, BIG5, GBK, UHC and GB18030 as client encodings,
but we cannot use them as server encodings. Are there any reason for it?
Very much so --- they aren't safe ASCII-supersets, and thus for example
the parser will fail on them.
Tom Lane [EMAIL PROTECTED] wrote:
PostgreSQL suppots SJIS, BIG5, GBK, UHC and GB18030 as client encodings,
but we cannot use them as server encodings. Are there any reason for it?
Very much so --- they aren't safe ASCII-supersets, and thus for example
the parser will fail on them.
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
Backend encodings must have the property
that all bytes of a multibyte character are = 128.
But then, PG_JOHAB have already infringed it. Please see johab_to_utf8.map.
Trailing bytes of JOHAB can be less than 128.
At Korea, Johab code is very old encondig.
by the way, cp949 code page is really used in most environments.
Personally speaking, Johab server code set is not need.
I think that PostgreSQL supports UHC (cp949) server code set.
This feature will be greet many Korean. :)
Unfortunately, UHC code
23 matches
Mail list logo
