Hi Tom,
I'm releaved now. the problem is solved
You're right. the problem was locales not installed.
I just ran "dpkg-reconfigure locales" and install the repsectives.
btw, I'm turned into a pgsql fan.
i just posted a thread at pgsql-sql
http://archives.postgresql.org/pgsql-sql/2007-12/index.php
"Iuri Sampaio" <[EMAIL PROTECTED]> writes:
> I don;t understand how it's related with postgresql installation. I never
> had this problem before.
> My locale is set:
> debian:~# locale -a
> C
> en_US.utf8
> POSIX
Well, your original report was about this:
FATAL: invalid value for parameter "lc_
Dave Page <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Just out of curiosity, why is pgAdmin doing it this way at all?
>> Seems it would be a lot easier to use the all-columns form of
>> pg_get_indexdef than to cons up the display from fetches of each
>> column individually.
> We use the data
Tom Lane wrote:
> I dug through the archives and found that we've had this discussion
> before ;-). The basic argument for having the per-column form of
> pg_get_indexdef do what it does was that it's unreasonable for
> client-side code to try to disassemble an expression tree string,
> whereas ex
Dave Page <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hm, there is a definitional issue here. Should pg_get_indexdef print
>> this stuff at all when colno is nonzero?
>> ...
>> Dave, I think we put in this variant of the function for pgAdmin ---
>> what does pgAdmin need?
> More is better fo
Hi Tomm
I don;t understand how it's related with postgresql installation. I never
had this problem before.
My locale is set:
debian:~# locale -a
C
en_US.utf8
POSIX
iuri de araujo sampaio
writes:
> No, I´m not sure.
> Assuming i´ve got a locale problem, how do i get rid of it?
> re-installin
Hi Tomm
I don;t understand how it's related with postgresql installation. I never
had this problem before.
My locale is set:
debian:~# locale -a
C
en_US.utf8
POSIX
iuri de araujo sampaio
writes:
> No, I´m not sure.
> Assuming i´ve got a locale problem, how do i get rid of it?
> re-installin
Hi Tomm
I don;t understand how it's related with postgresql installation. I never
had this problem before.
My locale is set:
debian:~# locale -a
C
en_US.utf8
POSIX
iuri de araujo sampaio writes:
> No, I´m not sure.
> Assuming i´ve got a locale problem, how do i get rid of it?
> re-installin
Tom Lane wrote:
> NikhilS <[EMAIL PROTECTED]> writes:
>>> Looks like pg_get_indexdef is unwell :-(
>
>> yes, it was unwell in the area where the amcanorder was being processed. The
>> attached patch should fix this.
>
> Hm, there is a definitional issue here. Should pg_get_indexdef print
> this
NikhilS <[EMAIL PROTECTED]> writes:
>> Looks like pg_get_indexdef is unwell :-(
> yes, it was unwell in the area where the amcanorder was being processed. The
> attached patch should fix this.
Hm, there is a definitional issue here. Should pg_get_indexdef print
this stuff at all when colno is no
iuri de araujo sampaio <[EMAIL PROTECTED]> writes:
> No, I´m not sure.
> Assuming i´ve got a locale problem, how do i get rid of it?
> re-installing postgres??
> I already tried that a couple of times and it didn´t succeed
> is it an option to re-install my OS (debian etch)?
> or just apt-get
Hi,
> >> CREATE INDEX test_desc_idx1
> >> ON test_desc
> >> USING btree
> >> (f1, f2 desc)
> >>
> >> CREATE INDEX test_desc_idx2
> >> ON test_desc
> >> USING btree
> >> (f1 desc, f2);
>
> postgres=# select pg_get_indexdef('test_desc_idx1'::regclass, 2, true);
> pg_get_indexdef
> -
Gregory Stark wrote:
"Zdenek Kotala" <[EMAIL PROTECTED]> writes:
I got dump of affected two blocks from Alex and it seems that both blocks were
overwritten together with some 128bytes length structure (there some pattern)
and complete damaged size is 9728bytes (first block is overwritten comple
So sorry, I send you only the half of information:
MS-SQL uses the the plan with only nested loops when i have abt less
than 100 tuples in both the tables (="small")
when t1 gets abt > 1000 tuples (="medium") it switches to the
hash-anti-semi-join, when both tables gets more than 1000 tuples
(="bi
Pavel Stehule wrote:
> Hello
>
> it's pgAdmin bug. please report it there
Actually it doesn't appear to be...
Using the OPs example code on 8.3 beta 4:
>> CREATE INDEX test_desc_idx1
>> ON test_desc
>> USING btree
>> (f1, f2 desc)
>>
>> CREATE INDEX test_desc_idx2
>> ON test_desc
>> U
Hello
it's pgAdmin bug. please report it there
Regards
Pavel Stehule
On 19/12/2007, Boonchai <[EMAIL PROTECTED]> wrote:
>
> The following bug has been logged online:
>
> Bug reference: 3829
> Logged by: Boonchai
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.3 beta
Hello
It's not bug. a LIKE 'some%' is different operation than a = str_const.
if you don't use C locale, then you have to use varchar_pattern_ops.
please try:
create index like_index on tab(str varchar_pattern_ops);
don't forget do ANALYZE tab before
Regards
Pavel Stehule
On 19/12/2007, d
The following bug has been logged online:
Bug reference: 3829
Logged by: Boonchai
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3 beta 4
Operating system: windows XP
Description:Wrong index reporting from pgAdmin III (v1.8.0 rev
6766-6767)
Details:
I create
db =# explain SELECT seq FROM tab WHERE str like 'edt%';
QUERY PLAN
---
Seq Scan on tab (cost=0.00..6465.55 rows=1 width=4)
Filter: (str ~~ 'edt%'::text)
(2 rows)
db=# explain SELECT seq FROM tab WHERE str = 'edta';
QUERY PLAN
---
19 matches
Mail list logo
