[BUGS] bug "\! cd"
I did '\i cd' on solaris. It doesn't change the directory. It stays where it is. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] bug: 2 dimensional array
Here is the sequence suggested in the Tutorial from your site:
CREATE TABLE SAL_EMP (
kathydb(# nametext,
pkathydb(# ay_by_quarter integer[],
schedule kathydb(# text[][]
);
INSERT INTO SAL_EMP
VAkathydb-# LUES ('Bill',
kathydb(# '{1, 1, 1, 1}',
'kathydb(# {{"meeting", "lunch"}, {}}');
select * from sal_emp;
name | pay_by_quarter | schedule
--+---+
Bill | {1,1,1,1} | {{"meeting"},{""}}
(1 row)
bug:
"Lunch" is gone.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] Bug #722: SELECT FOR UPDATE bug
Pablo Aviles 27/07/2002 10:58 To: Tom Lane <[EMAIL PROTECTED]> cc: Subject: Re: [BUGS] Bug #722: SELECT FOR UPDATE bugLink Hi, we are use Postgresql 7.3. The case in questions is: we have many clients (pc's) of postgresql. Every client try to block an employee to display at user. The user make change in the employee, but nobody can take the same employee at same time. Before changes, the next step is update the record (Record blocked) But, when I use > SELECT * FROM employees > WHERE status = 'A' > LIMIT 1 > FOR UPDATE; to catch the employee, only the first user select a record. Other users can`t select any employee until the first user release the record. The first conclusion here, is that Postgresql block all employee table. When we try to use the LOCK sentence, the result don´t have change. regards, Pablo Avilés Cisneros Technology, ITS Software Development Area Technology, ITS San José, Costa Rica email: [EMAIL PROTECTED] Tom Lane <[EMAIL PROTECTED]> 27/07/2002 09:58 To: [EMAIL PROTECTED], [EMAIL PROTECTED] cc: Subject: Re: [BUGS] Bug #722: SELECT FOR UPDATE bug [EMAIL PROTECTED] writes: > SELECT * FROM employees > WHERE status = 'A' > LIMIT 1 > FOR UPDATE; > The problem, in the previous sentence, is block every record on > employees, although we want one record, we want limit 1. I do not believe that. Could you give a more complete example of your problem? It would also help if you'd state which Postgres version you're using. regards, tom lane
[BUGS] Money locale currency symbol position
POSTGRESQL BUG REPORT TEMPLATE Your name : Marko Mikulicic Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : * Operating System (example: Linux 2.0.26 ELF) : Linux 2.4.18 PostgreSQL version (example: PostgreSQL-7.2.1): PostgreSQL-7.2.1 Compiler used (example: gcc 2.95.2) : * Please enter a FULL description of your problem: src/backend/utils/adt/cash.c doesn't handle currency position at all. It assumes that the currency symbol is at beggining of the string. This is not acceptable for localized application. The situation is also aggravated by the absence of the separator whitespace: good: 12,32 F bad: F12,32 Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- set a european locale (say fr_FR) and start the database. select 0::money; it should output: 0,00 F If you know how this problem might be fixed, list the solution below: - The more general soultion would be to use "strfmon" function to handle monetary output and completely ignore currency from input (either at beginning or at end) and use "strtod" for locale support (decimal point). The code in cash.c should be cleaned up completely from hand-made locale handling because it is not conforming to the standards, and since glibc has done the job much better. I'm not sure, but it seems that "strfmon" is POSIX. I suggest that for platforms which does not support strfmon (if it is really POSIX) either drop locale support or provide a "strfmon"/"strtod" emulation in a separated file/lib in order to minimize dependencies with cash. This emulation could be based on code from glibc, if possible. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] Multi-byte character bug
Two bugs has been found in the SQL parser and Multibyte char support: 1. ¡§Problem connecting to database: java.sql.SQLException: ERROR: Invalid EUC_TW character sequence found (0xb27a)¡¨ was reported in using JDBC driver to insert record, similar error reported when using ODBC driver and psql, since auto-conversion from client to server should convert the charcter to a valid EUC_TW char, therefore this is a bug 2. inserting record with ¡§À\¡¨ chinese char, the SQL parser report something like ¡¥Problem connecting to database: java.sql.SQLException: ERROR: parser: parse error at or near "4567891"¡¦ (similar in jdbc and odbc), and the error ¡§unterminated string¡¨ has been reported when using psql. I¡¦ve found the problem exists since 7.1.x till 7.2.*.
[BUGS] Select For Update bug???
Hi, I'm encountered a problem with a select for update sentence with postgresql. If I use...: begin transaction; select * from employees where status = 'A' limit 1 for update; ... The problem, in the previous sentence, is block every record on employees, although we want one record, we want limit 1. The bug it seems the limit 1, because if I dispose the limit 1 line, only the return records are blocked. If I use: begin transaction; select * from employees where (status = 1) and (id_employee = 123) order by id_employee for update; ... it block every record on employees, although we want one record, we want id_employee = 123. The bug it seems the order by line, because if I dispose the order by line, only the return records are blocked. Do you have an alternative way? Is this a bug? Any suggestion? I'm using Delphi 6 with dbexpress, and the transaction was make with an TSQLClientDataSet component after an TSQLConnection Pablo Avilés Cisneros Technology, ITS Software Development Area Technology, ITS San José, Costa Rica email: [EMAIL PROTECTED]
[BUGS] share lib libpq++
Hi, installation from postgres7.2.1.tar.gz. The automatic installation does not create lib/libpq++.so. In src/interfaces/libpq++, there is a Makefile which generates fpic command directly (instead of gcc ... -fpic ...) and of course the fpic command does not exist. Using gcc -fpic pgconnection.o pgconnection.cc.., we get then following error : pgconnection.h:86 ISO C++ forbids declaration of strings "with no type". Any helps would be appreciated. Thanx Serge and hubert ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] bug "\! cd"
On 2002.07.26 at 12:00:01 -0600, Kathy zhu wrote: > I did '\i cd' on solaris. > It doesn't change the directory. It stays where it is. It is not a bug, it is a feature. Of any Unix, including Solaris, Linux etc. Current directory is a propriety of running process. When process is finished, its current directory is forgotten, and parent process doesn't know anything about it. \! in psql starts shell as child process and executes given command in it. So, executing a command "cd" couldn't affect psql process by design. If there is a bug, it is that there is no backslash-command to change working direcory. But there is such command - \cd, at least in 7.2.1 -- Victor Wagner [EMAIL PROTECTED] Chief Technical Officer Office:7-(095)-748-53-88 Communiware.Net Home: 7-(095)-135-46-61 http://www.communiware.net http://www.ice.ru/~vitus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Multi-byte character bug
> Two bugs has been found in the SQL parser and Multibyte char support: > > 1. ¡§Problem connecting to database: java.sql.SQLException: ERROR: > Invalid EUC_TW character sequence found (0xb27a)¡¨ was reported in using > JDBC driver to insert record, similar error reported when using ODBC > driver and psql, since auto-conversion from client to server should > convert the charcter to a valid EUC_TW char, therefore this is a bug How did you set the auto-conversion settings for psql? I suspect you did something wrong with it. > 2. inserting record with ¡§À\¡¨ chinese char, the SQL parser > report something like ¡¥Problem connecting to database: > java.sql.SQLException: ERROR: parser: parse error at or near "4567891"¡¦ > (similar in jdbc and odbc), and the error ¡§unterminated string¡¨ has > been reported when using psql. > > I¡¦ve found the problem exists since 7.1.x till 7.2.*. What is the encoding for "chinese char"? You need to give us more info. -- Tatsuo Ishii P.S. Please don't post with non-ascii chars. If you need to show non-ascii chars, you should give them in a hex form. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] Bug #722: SELECT FOR UPDATE bug
On Fri, 26 Jul 2002 [EMAIL PROTECTED] wrote:
> Pablo Aviles
> 27/07/2002 10:58
>
>
> To: Tom Lane <[EMAIL PROTECTED]>
> cc:
> Subject:Re: [BUGS] Bug #722: SELECT FOR UPDATE bug
>
>
> Hi,
> we are use Postgresql 7.3.
> The case in questions is: we have many clients (pc's) of postgresql. Every
> client try to block an employee to display at user. The user make change
> in the employee, but nobody can take the same employee at same time.
> Before changes, the next step is update the record (Record blocked)
>
> But, when I use
> > SELECT * FROM employees
> > WHERE status = 'A'
> > LIMIT 1
> > FOR UPDATE;
> to catch the employee, only the first user select a record. Other users
> can`t select any employee until the first user release the record. The
If you use that same query in two transactions of course it's going to
block, they're almost certainly going to try to get the same record and
the second'll block since the first already has the lock.
When I do the following:
sszabo=# create table employee(name text, status char(1));
CREATE TABLE
sszabo=# insert into employee('a', 'a');
ERROR: parser: parse error at or near "'a'"
sszabo=# insert into employee values('a', 'a');
INSERT 8567431 1
sszabo=# insert into employee values('b', 'a');
INSERT 8567432 1
sszabo=# insert into employee values('c', 'b');
INSERT 8567433 1
Transaction 1:
begin;
sszabo=# select * from employee where status='a' for update limit 1;
name | status
--+
a| a
(1 row)
Transaction 2:
sszabo=# begin;
BEGIN
sszabo=# select * from employee where status='a' and name='b' for update
limit 1;
name | status
--+
b| a
(1 row)
Whereas running the same query in both causes the second to block until
the first finishes. If I update the first transaction's row in that
transaction so that it doesn't match, the second query doesn't return
anything, which might be a bug however (I'm not sure what should
happen in that case)
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [BUGS] Money locale currency symbol position
Marko Mikulicic <[EMAIL PROTECTED]> writes: >The code in cash.c should be cleaned up completely Such criticism is best expressed in the form of a patch ;-) Note though that most of us think the current money type is a kluge anyway; anything based on int4 storage doesn't have enough significant digits. It would be better rewritten as a thin locale-aware veneer over type "numeric". regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Money locale currency symbol position
Marko Mikulicic <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Note though that most of us think the current money type is a kluge >> anyway; anything based on int4 storage doesn't have enough significant >> digits. It would be better rewritten as a thin locale-aware veneer >> over type "numeric". > I agree. > Is there an example of how to inherit from a parametrized type ? I think you could mostly do this with binary compatibility: if money were binary-equivalenced to numeric then most of the right things would happen. (Compare type regproc to type oid --- regproc has no behavior other than special I/O functions, and still manages to inherit most of oid's other behaviors.) One thing you would not get out of that is the ability to say "money(m,n)" to specify precision --- that would take specialized hacking in the parser. But I'm not sure you want it. The preferred number of fractional digits should be determined from the monetary locale, *not* from any SQL declaration. And there's no good reason to limit the total number of digits at all. > Is possible to view the CREATE TYPE command which creates the > internal type numeric? There is no such command, because internal types are "created" by direct insertions of rows into pg_type during initdb. Look at the contents of src/include/catalog/pg_type.h. > If you want to use numeric I guess you cannot use strfmon because it uses > float or double and it's not arbitrary precision. Ugh. Time to start writing code :-( regards, tom lane ---(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] Select For Update bug???
What PostgreSQL version are you using? Please try this in two psql sessions and see if you see the same thing. --- [EMAIL PROTECTED] wrote: > Hi, I'm encountered a problem with a select for update sentence with > postgresql. > > If I use...: > begin transaction; > select * from employees > where status = 'A' > limit 1 > for update; > ... > > The problem, in the previous sentence, is block every record on employees, > although we want one record, we want limit 1. The bug it seems the limit > 1, because if I dispose the limit 1 line, only the return records are > blocked. > > If I use: > begin transaction; > select * from employees > where (status = 1) and (id_employee = 123) > order by id_employee > for update; > ... > it block every record on employees, although we want one record, we want > id_employee = 123. The bug it seems the order by line, because if I > dispose the order by line, only the return records are blocked. > > Do you have an alternative way? Is this a bug? Any suggestion? > > I'm using Delphi 6 with dbexpress, and the transaction was make with an > TSQLClientDataSet component after an TSQLConnection > > > Pablo Avil?s Cisneros > Technology, ITS > Software Development Area > Technology, ITS > San Jos?, Costa Rica > email: [EMAIL PROTECTED] > > [ image/gif is not supported, skipping... ] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
