[BUGS] beta - win32, restore from pg_dump not possible
Hello, Testing out beta version of 8.0 on XP Pro. I am trying to use psql to restore a dump of my database (prod. version runs under cygwin). Whenever I execute psql the password prompt is displayed and skipped right over which results in the command failing. psql.exe mydb < c:\mybackup file is the command I am executing. Even if I use the -U option it still prompts for a password and then automatically jumps to the next step without me having a chance to enter the password. Mike ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] Substring function incorrect when searching for '@.'
To reproduce: create a table with a data type of varchar (50) and name it email insert into this table the following values: [EMAIL PROTECTED] Execute the following statement: SELECT CASE WHEN count(substring(email FROM '@.')) > 0 THEN count(substring(email FROM '@.')) ELSE 0 END, email FROM your_schema.your_table GROUP BY email; Result with be equal to 1 / True. It should be 0 / False. If you execute the above but replace '@.' with '@a' it will also return 1 / True is correct. The only time it fails for me is if the @ is immediately followed by a period. 7.3.4 using psql via pgadminIII under cygwin. Mike ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] BUG #1629: subquery IN returns incorrect results
The following bug has been logged online:
Bug reference: 1629
Logged by: mike g
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0
Operating system: Windows 2000
Description:subquery IN returns incorrect results
Details:
If I run this query:
SELECT distinct CAST(newprogram as varchar(60)) FROM
(SELECT t.propnbr,
CASE WHEN t.propname = 'A' THEN 'Am'
WHEN t.propname = 'B' THEN 'AMm'
WHEN t.propname = 'C' THEN 'I might vanish'
WHEN t.propname = 'D' THEN 'Bem'
WHEN t.propname = 'E' THEN 'Cm'
WHEN t.propname = 'F' THEN 'Clm'
WHEN t.propname = 'G' THEN 'Com'
WHEN t.propname = 'H' THEN 'Dm'
WHEN t.propname = 'I' THEN 'Er'
WHEN t.propname = 'J' THEN 'Err'
WHEN t.propname = 'K' THEN 'Em'
WHEN t.propname = 'L' THEN 'Fm'
WHEN t.propname = 'M' THEN 'Fm'
WHEN t.propname = 'N' THEN 'Gm'
WHEN t.propname = 'O' THEN 'Hm'
WHEN t.propname = 'P' THEN 'Dm'
WHEN t.propname = 'Q' THEN 'Lm'
WHEN t.propname = 'R' THEN 'Nm'
WHEN t.propname = 'S' THEN 'Om'
WHEN t.propname = 'T' THEN 'Err'
WHEN t.propname = 'U' THEN 'Rm'
WHEN t.propname = 'V' THEN 'Tm'
WHEN t.propname = 'W' THEN 'Tm'
ELSE t.propname
END as newprogram
FROM example_data t
INNER JOIN example_data2 b ON t.propco = b.propco
WHERE
upper(b.serviced) = 'STATE1' and
t.propname in ('A',
'B'
'C', --switch me
'D', -- and switch me
'E',
'F',
'G',
'H',
'I',
'J',
'K',
'L',
'M',
'N',
'O',
'P',
'Q',
'R',
'S',
'T',
'U',
'V',
'W',
'X')) as my_data
My results are:
newprogram
Am
Bem
Clm
Cm
Com
Dm
Em
Er
Err
Fm
Gm
Hm
Lm
Nm
Om
Rm
Tm
If I just change the order of the data for the IN subquery portion
SELECT distinct CAST(newprogram as varchar(60)) FROM
(SELECT t.propnbr,
CASE WHEN t.propname = 'A' THEN 'Am'
WHEN t.propname = 'B' THEN 'AMm'
WHEN t.propname = 'C' THEN 'I might vanish'
WHEN t.propname = 'D' THEN 'Bem'
WHEN t.propname = 'E' THEN 'Cm'
WHEN t.propname = 'F' THEN 'Clm'
WHEN t.propname = 'G' THEN 'Com'
WHEN t.propname = 'H' THEN 'Dm'
WHEN t.propname = 'I' THEN 'Er'
WHEN t.propname = 'J' THEN 'Err'
WHEN t.propname = 'K' THEN 'Em'
WHEN t.propname = 'L' THEN 'Fm'
WHEN t.propname = 'M' THEN 'Fm'
WHEN t.propname = 'N' THEN 'Gm'
WHEN t.propname = 'O' THEN 'Hm'
WHEN t.propname = 'P' THEN 'Dm'
WHEN t.propname = 'Q' THEN 'Lm'
WHEN t.propname = 'R' THEN 'Nm'
WHEN t.propname = 'S' THEN 'Om'
WHEN t.propname = 'T' THEN 'Err'
WHEN t.propname = 'U' THEN 'Rm'
WHEN t.propname = 'V' THEN 'Tm'
WHEN t.propname = 'W' THEN 'Tm'
ELSE t.propname
END as newprogram
FROM example_data t
INNER JOIN example_data2 b ON t.propco = b.propco
WHERE
upper(b.serviced) = 'STATE1' and
t.propname in ('A',
'B'
'D', -- and switch me
'C', --switch me
'E',
'F',
'G',
'H',
'I',
'J',
'K',
'L',
'M',
'N',
'O',
'P',
'Q',
'R',
'S',
'T',
'U',
'V',
'W',
'X')) as my_data
Gives this for a result
Am
Clm
Cm
Com
Dm
Em
Er
Err
Fm
Gm
Hm
I might vanish
Lm
Nm
Om
Rm
Tm
I will email a pg_dump of the two tables on request.
The results of either version are incorrect.
If you remove the IN subquery and replace each case with t.propname = 'A'
or... then correct results returned:
AMm
Am
Bem
Clm
Cm
Com
Dm
Em
Er
Err
Fm
Gm
Hm
I might vanish
Lm
Nm
Om
Rm
Tm
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #1629: subquery IN returns incorrect results
Sorry, I used the online bug reporting form and it doesn't have an option to attach a file to it. If it had I would have attached a pg_dump file. Mike On Wed, Apr 27, 2005 at 10:57:42AM -0400, Tom Lane wrote: > "mike g" <[EMAIL PROTECTED]> writes: > > Description:subquery IN returns incorrect results > > It's impossible to investigate this with the amount of information you > have provided. Please show a *self contained* example, including any > table declarations and test data needed. > > regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] BUG #1629: subquery IN returns incorrect results
[snip]
You are correct about the comma missing between the B and C in the query. It is
turning it into B'C. I can't think of a good way for postgres to try and
generate a warning in case a typo like this is made.
Thank you.
Mike
>
> Unless this is a copy/paste error, you have missed a , in your query. Which
> effectively turns it into
> ('A', 'B''C', 'D' ...
>
> Which mean that switching those two will give incorrect results. One will be
> missing C, and it will be included with B,
> and the other D for the same reason.
>
> > 'C', --switch me
> > 'D', -- and switch me
> > 'E',
> > 'F',
> [snip]
>
> Regards
>
> Russell Smith.
>
> ---(end of broadcast)---
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
---(end of broadcast)---
TIP 3: 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: [BUGS] BUG #1635: Failed to create process for initdb
Did you remove the postgres user account before reinstalling? On Wed, Apr 27, 2005 at 06:49:59PM +0100, Tom wrote: > > The following bug has been logged online: > > Bug reference: 1635 > Logged by: Tom > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.0 > Operating system: Windows 2000 > Description:Failed to create process for initdb > Details: > > I'm trying to reinstall PostgreSQL and during the install I'm getting the > following error. Then it shuts down the install. > > Failed to create process for initdb: Logon failure: unknown user name or bad > password > > ---(end of broadcast)--- > TIP 3: 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1638: ODBC driver problem
I believe the ODBC package is managed by a different group. Bugs can be viewed and added here: http://gborg.postgresql.org/project/psqlodbc/bugs/buglist.php Mike On Fri, Apr 29, 2005 at 04:31:02PM +0100, Vig Sandor wrote: > > The following bug has been logged online: > > Bug reference: 1638 > Logged by: Vig Sandor > Email address: [EMAIL PROTECTED] > PostgreSQL version: ANY ( now: 8.0) > Operating system: ANY (XP, W2k, Linux...) > Description:ODBC driver problem > Details: > > Hi, > > I wrote an application (in Cbuilder 5, using BDE) > the was just working fine with the ODBC driver in > "psqlodbc-07_03_0200.zip". With the latest ODBC drivers > the program crashes after sending the first query. > (connect is successfull) It raises a null pointer > exception. After downgrading the ODBC driver, it's > all OK. I tested it with different servers, clients, > psql server versions, at home, at work, etc.. but > it was always the same. > > Please help. > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
