Hi All,
I am trying to configure CVS through Eclipse, infact i was able to do that but
when I map the postgreSQL code into CVS through Eclipse, it is displaying the
folders but the files in those folders are not getting displayed.
Can anyone help me over this..
Thanks in advance
Cinu Kuriakos
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,
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.
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
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
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
-
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.
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_c
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* perspec
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)---
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_c
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 J
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
i
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.93
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
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
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
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 numeri
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 canno
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 r
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 p
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?
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 continu
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
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)-
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 o
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'
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 loca
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:
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 n
[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
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 no
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 th
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
"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 changin
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
> Ol
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
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
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
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 fe
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
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 tim
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 e
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 e
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.00
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
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 relatio
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 archi
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
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
50 matches
Mail list logo
