[BUGS] field-update in before-trigger causes distinct to 'fail', new in v8.1 versus v8.0.4, demo-sql included
L.S. I noticed that after creating these necessary objects: create table t_src(value int); create table t_dest(value int primary key); create or replace function tr_t_dest_before_iud() returns trigger language 'plpgsql' volatile strict security invoker AS 'declare begin RAISE NOTICE ''tr_t_dest_before_iud() triggered for value (%)'', NEW.value; NEW.value = NEW.value + 1; RETURN NEW; END;'; create trigger t_dest_before before insert or update or delete on t_dest for each row execute procedure tr_t_dest_before_iud(); insert into t_src values (1); insert into t_src values (5); insert into t_src values (9); insert into t_src values (5); The following statement causes an error due to the fact that the distinct isn't producing distinct values anymore. db=# insert into t_dest select distinct value from t_src; NOTICE: tr_t_dest_before_iud() triggered for value (1) NOTICE: tr_t_dest_before_iud() triggered for value (5) NOTICE: tr_t_dest_before_iud() triggered for value (5) ERROR: duplicate key violates unique constraint "t_dest_pkey" This seems to be caused by the update of 'value' in the before-trigger. Removing the update will let the distinct produce proper results. 4cleanup: drop table t_dest; drop table t_src; drop function tr_t_dest_before_iud(); select version(); version PostgreSQL 8.1.0 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.4.3 (1 row) -- Best, Frank. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #2039: Problem with Installation
The following bug has been logged online: Bug reference: 2039 Logged by: Ramesh Nagu Tummala Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.1 Operating system: WinXP Professional Description:Problem with Installation Details: Iam trying to install postgresql in my system but my system was FAT32 Data allocation but i software downloaded for NTFS. My doubt is cant we install postgresql on FAT32? if so please provide the link to download. else we need to format my system in NTFS and install the software? please guide me to secure way of installation . ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #2041: annoyance with COPY
The following bug has been logged online: Bug reference: 2041 Logged by: sebastien mayer Email address: [EMAIL PROTECTED] PostgreSQL version: 8.04 Operating system: linux fedora core 4 Description:annoyance with COPY Details: in : copy table to file got the constraint that 'file' has to be a literal. 'file' can not be a text variable. That is not fair ! I want peoples using my application creates backup of parts of the data. The directory where the extracted data is something like : /tmp/briosoft_temp// So i construct a text variable to hold the filename. In fact the whole command that i EXECUTE. The usage could be simplified if you accept text variable as 'file'. By the way, as soon as you want to deal with backups of datas and large_objects, you touch the file system : in a large company, the 1000's of users will not have all a DVD writer ! There is a centralized computer department where peoples deals with archive DVD-ROM's and sometimes send them back to the user who asked for it. This means we need functions to mkdir, rmdir, even a system call in order to tar and mkisofs the result of the backup/archive. We could even cdrecord !! OK, you don't want SQL becomes PHP. Anyway, with the opportunity to add functions with C, you may consider the question answered. have a good day seb ---(end of broadcast)--- TIP 1: 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
[BUGS] BUG #2042: Installation failed
The following bug has been logged online:
Bug reference: 2042
Logged by: mattias
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.0.2.
Operating system: Windows XP Pro
Description:Installation failed
Details:
Downloaded postgresql-8.1.0-2.zip
and installed and got this.
Internal account lookup failure: No mapping between accound names and
security IDs was done.
Tried it twice. I never installed PG before, but I have mysql and sqlserver
on the same machine.
This is the end of the log file:
Property(S): CostingComplete = 1
Property(S): OutOfDiskSpace = 0
Property(S): OutOfNoRbDiskSpace = 0
Property(S): PrimaryVolumeSpaceAvailable = 0
Property(S): PrimaryVolumeSpaceRequired = 0
Property(S): PrimaryVolumeSpaceRemaining = 0
Property(S): SOURCEDIR = C:\install\postgresql\
Property(S): SourcedirProduct = {34D95765-2D5A-470F-A39F-BC9DEAAAF04F}
Property(S): ProductToBeRegistered = 1
MSI (s) (C8:20) [12:35:28:600]: MainEngineThread is returning 1603
MSI (s) (C8:28) [12:35:28:610]: Destroying RemoteAPI object.
MSI (s) (C8:88) [12:35:28:610]: Custom Action Manager thread ending.
MSI (c) (54:38) [12:35:28:620]: Back from server. Return value: 1603
MSI (c) (54:38) [12:35:28:620]: Decrementing counter to disable shutdown. If
counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (54:38) [12:35:28:620]: PROPERTY CHANGE: Deleting SECONDSEQUENCE
property. Its current value is '1'.
Action ended 12:35:28: ExecuteAction. Return value 3.
MSI (c) (54:38) [12:35:28:620]: Doing action: Fatal_Error
Action 12:35:28: Fatal_Error.
Action start 12:35:28: Fatal_Error.
Action 12:35:28: Fatal_Error. Dialog created
Action ended 12:35:31: Fatal_Error. Return value 2.
Action ended 12:35:31: INSTALL. Return value 3.
---(end of broadcast)---
TIP 6: explain analyze is your friend
[BUGS] BUG #2040: buggy cast of INT8 to text
The following bug has been logged online: Bug reference: 2040 Logged by: Sebastien MAYER Email address: [EMAIL PROTECTED] PostgreSQL version: 8.04 Operating system: Linux Fedora core 4 Description:buggy cast of INT8 to text Details: in plpgsql : declare var_text text; var_int8 INT8; begin var_int8 := 123456; -- next line give some strange result... but not always var_text := 'the value of var_int8 is ' || var_int8; end; I wrote a small b_bigint_to_text(int8) returns text and will use it until i see some fix on this. More generally, the oid, wich is int4 does not fit the currval, nextvall etc wich returns int8. Since you moved the serial concept from 32 bits to 64 bits (which look good to me), you still have old 32 bits style functions and variable (oid !) mixed with the new 64 bits concept. But, i thanks you everyday of my programmer life anyway ! seb ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #2042: Installation failed
> The following bug has been logged online: > > Bug reference: 2042 > Logged by: mattias > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1.0.2. > Operating system: Windows XP Pro > Description:Installation failed > Details: > > Downloaded postgresql-8.1.0-2.zip > > and installed and got this. > > Internal account lookup failure: No mapping between accound > names and security IDs was done. > > > Tried it twice. I never installed PG before, but I have mysql > and sqlserver on the same machine. Whoa. Interesting. Never seen that one before. Are you by any chance using a domain account? What's the name of the account you are using? //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #2039: Problem with Installation
> Bug reference: 2039 > Logged by: Ramesh Nagu Tummala > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.0.1 > Operating system: WinXP Professional > Description:Problem with Installation > Details: > > Iam trying to install postgresql in my system but my system > was FAT32 Data allocation but i software downloaded for NTFS. > > My doubt is cant we install postgresql on FAT32? if so please > provide the link to download. You can install it on FAT32, but you have to do it manually. It's also very much recommended that you don't run it on FAT32 for reliability issues. Finally, some features (in particular, tablespaces) do not work on FAT32. You need to download the binaries-no-installer and go from there. > else we need to format my system in NTFS and install the software? This is definitly the recommended way. Note that you can use the "convert" utility (just type convert /? on the commandline for help) to convert your existing system without the need to reformat. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2040: buggy cast of INT8 to text
"Sebastien MAYER" <[EMAIL PROTECTED]> writes: > -- next line give some strange result... but not always >var_text := 'the value of var_int8 is ' || var_int8; Couldn't duplicate a problem here ... you need to give a reproducible test case if you want anyone to look into this. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] field-update in before-trigger causes distinct to 'fail', new in v8.1 versus v8.0.4, demo-sql included
Frank van Vugt <[EMAIL PROTECTED]> writes: > The following statement causes an error due to the fact that the distinct > isn't producing distinct values anymore. > This seems to be caused by the update of 'value' in the before-trigger. Fix committed --- thanks for the report! regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] field-update in before-trigger causes distinct to 'fail', new in v8.1 versus v8.0.4, demo-sql included
Frank van Vugt <[EMAIL PROTECTED]> writes: > (NB what would be the best way to get to such a patch without bothering you? > I > looked at the webcsv, but I wasn't sure whether you changed anything outside > of execMain.c and execUtils.c and I'm not sure how to find out ;)) Looking at the pgsql-committers message is the easiest way to verify which files were touched: http://archives.postgresql.org/pgsql-committers/2005-11/msg00307.php It also provides links that will give you the per-file diffs directly. In this case, since the patch touches the widely known EState struct, I'd recommend a full backend recompile after patching. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2024: Wrong Greek ISO-encoding assignment
Nikolaos Papageorgiou wrote: > > The following bug has been logged online: > > Bug reference: 2024 > Logged by: Nikolaos Papageorgiou > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1.0.1 > Operating system: Windows 2000 Professional & XP Pro > Description:Wrong Greek ISO-encoding assignment > Details: > > Dear Sirs, > > I have been using your marvellous product for sometime now and I have come > across a rather unusual bug. > > It is supposed that Greek ISO-encoding is ISO-8859-7. > For some unknown reason from version 8.1 it is encoded as ISO-8859-6 which > is normally used by Arabic language and ISO-8859-7 produces Hebrew. It is > probably a one codepage shift left. > > Please correct it or let me know what is really happening I think it gets the encoding from the XP system settings. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2024: Wrong Greek ISO-encoding assignment
Unfortunately it has the same behaviour both under Windows 2000 and XP alike! To confirm my suspicion I have concurrently used EnterpriseDB in both enviroments, which works perfectly well with ISO-8859-7 for Greek. I would very much appreciate if you could take another look to this issue! Best regards, Nikolaos Papageorgiou [EMAIL PROTECTED] 2005-11-15 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
