Re: [BUGS] BUG #1970: Existing /etc/pam.d/postgresql clobbered by RPM
Mark Gibson wrote: The following bug has been logged online: Bug reference: 1970 Logged by: Mark Gibson Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.4 Operating system: Redhat Enterprise Linux 4 Description:Existing /etc/pam.d/postgresql clobbered by RPM install Details: Hello, I noticed that when installing the 8.0.4 RPM's it replaced our existing /etc/pam.d/postgresql - this caused our system to break temporarily, as it was missing the following line: account required pam_stack.so service=system-auth I don't know whether this is required for all systems or is just a peculiarity of our setup, but could the RPM be changed to not clobber this file in the future. I believe some RPM's install conflicting configs with the .rpmnew extension. Cheers. Please report this to the RPM maintainer. We do not create the RPMs. -- 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 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #1970: Existing /etc/pam.d/postgresql clobbered by
Hi, On Mon, 24 Oct 2005, Bruce Momjian wrote: snipped Please report this to the RPM maintainer. We do not create the RPMs. I thought we do? Our RPMs are marked as PGDG RPMs... -- Devrim GUNDUZ Kivi Bilişim Teknolojileri - http://www.kivi.com.tr devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] access postgresql from GTK+ GUI
Hi, Somesh here from Aerospace Systems Pvt Ltd., I am facing some problem in accessing postgresql database in GTK GUI with Linux environment. Please can u guide me how to set path for GTK and PostgreSQL to insert and retrive data from the database, and what are the settings i have to do for this Redhat linux. Thank you, somesh ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #1992: ODBC error with PostgreSQL Win32 Clients
The following bug has been logged online: Bug reference: 1992 Logged by: Paul Anderson Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3 Operating system: Microsoft Windows XP Professional version 5.1.2600 Service Pack 1 Build 2600 Description:ODBC error with PostgreSQL Win32 Clients Details: Error may not be with Postress per say but with the ODBC diriver. Installed pgw32cli-1[1].0.0.2-full.exe. Select Version(); PostgreSQL 8.0.3 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2 (mingw-special) I created an ODBC connection using the Postgres driver through the ODBC admin tool Am running Microsoft Word 2002 SP2. I am trying to use the mail merge functions to estalish a dynamic table link to Postgres. This is done by choosing insert database from the mail merge menu It brings up a dialog box to get data. choose new source choose ODBC DSN choose the pre-creared PostgreSQL DSN It returns an error unable to obtain a list of tables from the data source. The same error can be reproduced through Excelif you choose Data|Import External Data|Import Data The ODBC connection DOES work if you choose Data|Import External Data|New Database Query My need is to dynamically embedd reports into a word documents so I can distribute pre-formated reports so the excell option is not a viable option for what I need. The work around is to export the data from Postgres as tab delimeted text files and then have word connect to the text files. This is workable but cumbersome. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #1995: problem in createuser's french traduction
The following bug has been logged online: Bug reference: 1995 Logged by: Jean-Claude Caty Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.4 Operating system: linux debian unstable Description:problem in createuser's french traduction Details: while creating a user, createuser ask (in french) 1. Le nouvel utilisateur a-t'il le droit de créer des bases de données ? (y/n) if you respond 'y', it's not possible to create database. User have to say 'o' (for Oui) to be able to create database. So, I don't know if bug is in the traduction's question (y/n instead of o/n) or in createuser itself ... 2. It's the same problem with next question : Le nouvel utilisateur a-t'il le droit de créer des utilisateurs ? (y/n) ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] BUG #1993: Adding/subtracting negative time intervals changes time zone of result
The following bug has been logged online: Bug reference: 1993 Logged by: Nicholas Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3,8.0.4,8.1 Operating system: Gentoo Linux Description:Adding/subtracting negative time intervals changes time zone of result Details: spatula ~ # psql -U postgres Welcome to psql 8.1beta1, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit postgres=# SELECT VERSION(); version -- PostgreSQL 8.1beta1 on i686-pc-linux-gnu, compiled by GCC i686-pc-linux-gnu-gcc (GCC) 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8) (1 row) postgres=# SELECT NOW()-interval '1 week'; ?column? --- 2005-10-17 08:52:37.355219+10 (1 row) postgres=# SELECT NOW()-interval '-1 week'; ?column? --- 2005-10-31 08:52:39.021583+11 (1 row) postgres=# ---(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] BUG #1988: keygen not implemented
Thanks for the info. I found a workaround by selecting the current value of the sequence after doing the insert. This however is not desirable since it requires another round trip call to the DB, and it requires PostGRE SQL specific code in my generic JDBC client. If the driver supported getGeneratedKeys(), client applications could perform better and be truly generic. Also looking at the release notes I see I'm not the only person asking for this feature... Good luck. -Original Message- From: Oliver Jowett [mailto:[EMAIL PROTECTED] Sent: Sunday, October 23, 2005 2:24 PM To: Mike Clements Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] BUG #1988: keygen not implemented Mike Clements wrote: Insert a row into the table using: Connection.prepareStatement(sql, Statement.RETURN_GENERATED_KEYS); The driver throws an exception saying this method is not yet implemented. This is an optional part of the JDBC spec, and the driver doesn't claim to support it in the metadata it provides (DatabaseMetaData.supportsGetGeneratedKeys() returns false). What it should do is create the prepared statement so when you execute it, the returned ResultSet has the generated primary key. Unfortunately this requires functionality in the backend that does not yet exist (support for INSERT .. RETURNING ..., or similar). -O ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #1990: Installer bug fails to make C:\program files..global
The following bug has been logged online: Bug reference: 1990 Logged by: Gregory Bronner Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.4 Operating system: Win2k professional Description:Installer bug fails to make C:\program files..global Details: The files belonging to this database system will be owned by user postgres. This user must also own the server process. The database cluster will be initialized with locale C. fixing permissions on existing directory C:/Program Files/PostgreSQL/8.0/data ... ok creating directory C:/Program Files/PostgreSQL/8.0/data/global ... initdb: could not create directory C:/Program Files: File exists initdb: removing contents of data directory C:/Program Files/PostgreSQL/8.0/data Ever seen this? ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] BUG #1991: UPPER problem on special characters
The following bug has been logged online: Bug reference: 1991 Logged by: Guillaume Smet Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1b3 Operating system: RHEL 3 Description:UPPER problem on special characters Details: Hi, I'm currently testing 8.1b3 to prepare our migration from 7.4 to 8.1. I have a µ (greek mu) in my database correctly encoded as UTF-8 (database encoding is UTF-8). A SELECT UPPER() on this character gives me an error: ERROR: invalid multibyte character for locale but I can display it with a simple SELECT. We cannot uppercase this character but I don't think it's an invalid character. PHP for example just returns µ when I try to strtoupper it. AFAIK UTF-8 support is stricter in 8.1 but I'm not sure it's the correct behaviour to return an error in this case. Thanks for your help. Regards -- Guillaume ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1986: Please include ONE BIG .txt and .HTML file in *docs*.tar.gz
| This ONE BIG file will help loading it off-line to a web=20 | browser (or=20 | editor *.txt), and to make quick searches on backward and forward. | =20 | This wouldn't be hard to implement. Are others interested in this? | | The original bug talked about Windows - I'd just like to add that on | Windows we will already do this on 8.1, in the form of a CHM file. | That doesn't mean we shouldn't do sometihng for other platforms, though If I mentioned Windows, that was a mistake. I was talking in general interest. The *.chm file is no subtitute for good text editor with excellent search capabilities like Emacs + M-x occur / C-s / C-r with word grabbing and all other features. Emacs is available to Win32 as well. The BIG HTML file is user friendly for student classes, where it it posisble to serch within the browser window with find to demonstrate the various places. The one HTML also servers as a Printer format. Jari ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #1994: Ignore the last bug report; this is a confusing time zone feature, not a bug
The following bug has been logged online: Bug reference: 1994 Logged by: Nicholas Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3,8.0.4,8.1 Operating system: Gentoo Linux Description:Ignore the last bug report; this is a confusing time zone feature, not a bug Details: I thought Postgres didn't support automatically dealing with daylight savings; I guess it does, hence the change in time zone when crossing the DST boundary. ---(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
Re: [BUGS] BUG #1990: Installer bug fails to make C:\program files..global
The following bug has been logged online: Bug reference: 1990 Logged by: Gregory Bronner Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.4 Operating system: Win2k professional Description:Installer bug fails to make C:\program files..global Details: The files belonging to this database system will be owned by user postgres. This user must also own the server process. The database cluster will be initialized with locale C. fixing permissions on existing directory C:/Program Files/PostgreSQL/8.0/data ... ok creating directory C:/Program Files/PostgreSQL/8.0/data/global ... initdb: could not create directory C:/Program Files: File exists initdb: removing contents of data directory C:/Program Files/PostgreSQL/8.0/data Ever seen this? Do you by any chance have a directory called c:\program? //Magnus ---(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
Re: [BUGS] BUG #1993: Adding/subtracting negative time intervals
Nicholas wrote: The following bug has been logged online: Bug reference: 1993 Logged by: Nicholas Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3,8.0.4,8.1 Operating system: Gentoo Linux Description:Adding/subtracting negative time intervals changes time zone of result Details: spatula ~ # psql -U postgres Welcome to psql 8.1beta1, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit postgres=# SELECT VERSION(); version -- PostgreSQL 8.1beta1 on i686-pc-linux-gnu, compiled by GCC i686-pc-linux-gnu-gcc (GCC) 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8) (1 row) postgres=# SELECT NOW()-interval '1 week'; ?column? --- 2005-10-17 08:52:37.355219+10 (1 row) postgres=# SELECT NOW()-interval '-1 week'; ?column? --- 2005-10-31 08:52:39.021583+11 Looks to mee like Daylight Savings has conveniently started. (1 row) postgres=# ---(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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #1985: cannot insert Chinese character into a table encoded
Jeff Tong wrote: The following bug has been logged online: Bug reference: 1985 Logged by: Jeff Tong Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1beta3 Operating system: Windows XP Description:cannot insert Chinese character into a table encoded with UTF8 Details: I am a traditional Chinese user in Hong Kong. 8.1beta3 for WinXP still cannot let me insert Chinese character into a table encoded with UTF8. I think it is very importance issue with CJK users who need Unicode encoded tables. Here is a screenshot I took from command prompt: http://www.tong.cc/pgsql8.1beta3.png Strange. We thought we fixed all the UTF-8/Chinese issues in 8.1. Can you tell us the Unicode byte code sequence that is being rejected? -- 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 2: Don't 'kill -9' the postmaster
[BUGS] BUG #1996: DISTINCT fails with national character varying
The following bug has been logged online: Bug reference: 1996 Logged by: Ludmil Tinkov Email address: [EMAIL PROTECTED] PostgreSQL version: 7.3.2 Operating system: RedHat 9.0 Description:DISTINCT fails with national character varying Details: create table depression(ID int, name national character varying(50)) insert into depression values(1, 'Ðна'); insert into depression values(2, 'Ðва'); insert into depression values(3, 'Ðна'); insert into depression values(4, 'Яна'); select distinct name from depression --the last statement returns only a single row --namely: Ðна --it should return 4 rows! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #1996: DISTINCT fails with national character varying
Ludmil Tinkov [EMAIL PROTECTED] writes: select distinct name from depression --the last statement returns only a single row --namely: Ðна --it should return 4 rows! This has been seen to happen when you select a database encoding that does not match the encoding expected by the postmaster's LC_CTYPE locale setting. It's really a bug in the locale definitions, if you ask me, but good luck getting the glibc guys to change those :-(. In the meantime, make sure your locale and encoding agree. 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] BUG #1993: Adding/subtracting negative time intervals
On Tue, 25 Oct 2005 08:51:59 +1000, Russell Smith [EMAIL PROTECTED] wrote: Nicholas wrote: postgres=# SELECT NOW()-interval '1 week'; ?column? --- 2005-10-17 08:52:37.355219+10 (1 row) postgres=# SELECT NOW()-interval '-1 week'; ?column? --- 2005-10-31 08:52:39.021583+11 Looks to mee like Daylight Savings has conveniently started. But the elapsed time for those results is only 6 days, 23 hours. That's changed since v7.4.7 template1=# select now(); now --- 2005-10-25 12:40:22.699545+10 (1 row) template1=# select now() + '1 week'::interval; ?column? -- 2005-11-01 13:40:33.85492+11 (1 row) template1=# select now() - '-1 week'::interval; ?column? --- 2005-11-01 13:40:46.707656+11 (1 row) template1=# select version(); version - PostgreSQL 7.4.7 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5) (1 row) +---+-+ : Klint Gore: Non rhyming: : EMail : [EMAIL PROTECTED] : slang - the: : Snail : A.B.R.I.: possibilities : : Mail University of New England : are useless : : Armidale NSW 2351 Australia : L.J.J. : : Fax : +61 2 6772 5376 : : +---+-+ ---(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
Re: [BUGS] BUG #1993: Adding/subtracting negative time intervals
Klint Gore [EMAIL PROTECTED] writes: That's changed since v7.4.7 Yup. '1 week' = '7 days' which is no longer the same as 7*24 hours. In particular, as of 8.1 local noon plus one day is still local noon, even if there was a DST change in between. Adding 24 hours, on the other hand, might give 11am or 1pm. regards, tom lane ---(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
Re: [BUGS] BUG #1993: Adding/subtracting negative time intervals
On Tue, Oct 25, 2005 at 12:48:10PM +1000, Klint Gore wrote: On Tue, 25 Oct 2005 08:51:59 +1000, Russell Smith [EMAIL PROTECTED] wrote: Looks to mee like Daylight Savings has conveniently started. But the elapsed time for those results is only 6 days, 23 hours. That's changed since v7.4.7 I think this item in the 8.1 Release Notes might be relevant: * Add an internal day field to INTERVAL so a one day interval can be distinguished from a 24 hour interval (Michael Glaesemann) Days that contain a daylight savings time adjustment are not 24 hours, but typically 23 or 25 hours. This change allows days (not fixed 24-hour periods) to be added to dates who's result includes a daylight savings time adjustment period. Therefore, while in previous releases 1 day and 24 hours were interchangeable interval values, in this release they are treated differently, e.g. '2005-05-03 00:00:00 EST' + '1 day' = '2005-05-04 00:00:00-04' '2005-05-03 00:00:00 EST' + '24 hours' = '2005-05-04 01:00:00-04' Here's an example and the results from 7.4.9, 8.0.4, and 8.1beta4: \x SET TimeZone TO 'Australia/NSW'; SELECT version(), now(), now() + interval'1 week', now() + interval'168 hours'; -[ RECORD 1 ]--- version | PostgreSQL 7.4.9 on sparc-sun-solaris2.9, compiled by GCC gcc (GCC) 3.4.2 now | 2005-10-25 13:35:43.663169+10 ?column? | 2005-11-01 14:35:43.663169+11 ?column? | 2005-11-01 14:35:43.663169+11 -[ RECORD 1 ]--- version | PostgreSQL 8.0.4 on sparc-sun-solaris2.9, compiled by GCC gcc (GCC) 3.4.2 now | 2005-10-25 13:35:45.459081+10 ?column? | 2005-11-01 14:35:45.459081+11 ?column? | 2005-11-01 14:35:45.459081+11 -[ RECORD 1 ]-- version | PostgreSQL 8.1beta4 on sparc-sun-solaris2.9, compiled by GCC gcc (GCC) 3.4.2 now | 2005-10-25 13:35:47.104595+10 ?column? | 2005-11-01 13:35:47.104595+11 ?column? | 2005-11-01 14:35:47.104595+11 -- Michael Fuhr ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #1993: Adding/subtracting negative time intervals
On Mon, Oct 24, 2005 at 11:21:52PM -0400, Tom Lane wrote: Klint Gore [EMAIL PROTECTED] writes: That's changed since v7.4.7 Yup. '1 week' = '7 days' which is no longer the same as 7*24 hours. In particular, as of 8.1 local noon plus one day is still local noon, even if there was a DST change in between. Adding 24 hours, on the other hand, might give 11am or 1pm. Should 24 hours be the same as 1 * 24 hours? The latter appears to be equal to 1 day, not 24 hours: test= SELECT '2005-10-29 12:00:00-06'::timestamptz + '24 hours'::interval; ?column? 2005-10-30 11:00:00-07 (1 row) test= SELECT '2005-10-29 12:00:00-06'::timestamptz + 1 * '24 hours'::interval; ?column? 2005-10-30 12:00:00-07 (1 row) test= SELECT '2005-10-29 12:00:00-06'::timestamptz + '1 day'::interval; ?column? 2005-10-30 12:00:00-07 (1 row) -- Michael Fuhr ---(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] BUG #1993: Adding/subtracting negative time intervals
Michael Fuhr [EMAIL PROTECTED] writes: Should 24 hours be the same as 1 * 24 hours? Yes, I would think so. The latter appears to be equal to 1 day, not 24 hours: Urgh. I think this is a serious thinko in Michael Glaesemann's rewrite of interval_mul. The application of interval_justify_hours is utterly wrong ... and in fact, I'm not sure it should be applied in any of the three functions that currently call it. I don't mind the user deciding he'd like to flatten '24 hours' to '1 day' but the basic arithmetic functions for intervals have no business doing that. Comments? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #1993: Adding/subtracting negative time intervals
Tom Lane wrote: Michael Fuhr [EMAIL PROTECTED] writes: Should 24 hours be the same as 1 * 24 hours? Yes, I would think so. The latter appears to be equal to 1 day, not 24 hours: Urgh. I think this is a serious thinko in Michael Glaesemann's rewrite of interval_mul. The application of interval_justify_hours is utterly wrong ... and in fact, I'm not sure it should be applied in any of the three functions that currently call it. I don't mind the user deciding he'd like to flatten '24 hours' to '1 day' but the basic arithmetic functions for intervals have no business doing that. The reason interval_justify_hours is called by interval multiplication is so multipling an interval '2 days, 4 hours' by 10 doesn't return values like 20 days, 40 hours, etc, but instead something like '21 days, 16 hours', which seems more reasonable. For a query like: test= SELECT '2005-10-29 12:00:00-06'::timestamptz + 1 * '24 hours'::interval; the interval multiplication really has no fixed timestamp associated with it, so it seems good to adjust the output. That result is _then_ added to an interval, and this is where the problem happens, where this computes to 1 day: test= select 1 * '24 hours'::interval; ?column? -- 1 day (1 row) I would say if intervals are going to be added to timestamps, we probably don't want the adjustment, but if they are going to be used on their own, it seems the adjustment makes sense. One solution would be to suggest the use of interval_justify_hours() in the documentation for interval multiplication, and prevent the justification from happening automatically. -- 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 6: explain analyze is your friend
Re: [BUGS] BUG #1993: Adding/subtracting negative time intervals
Bruce Momjian pgman@candle.pha.pa.us writes: Tom Lane wrote: Urgh. I think this is a serious thinko in Michael Glaesemann's rewrite of interval_mul. The reason interval_justify_hours is called by interval multiplication is so multipling an interval '2 days, 4 hours' by 10 doesn't return values like 20 days, 40 hours, etc, but instead something like '21 days, 16 hours', which seems more reasonable. That's utterly WRONG, though. The entire *point* of the 8.1 change is that days and hours are incommensurable. We are forced to down-convert in some cases --- for example, we can't compute a useful result for 0.5 * '1 day' without imputing 12 hours as the equivalent of 0.5 day --- but we never have to and never should up-convert, except by explicit user command ... which is what the justify_hours function is for. One solution would be to suggest the use of interval_justify_hours() in the documentation for interval multiplication, and prevent the justification from happening automatically. Exactly. Forcing the justification to happen is broken, because there's no way to get the other behavior. regards, tom lane ---(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
Re: [BUGS] BUG #1943: Lock A row with the option NoWait
On Thu, Oct 06, 2005 at 17:42:25 +0100, Mathias Laurent [EMAIL PROTECTED] wrote: The following bug has been logged online: Bug reference: 1943 Logged by: Mathias Laurent Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Operating system: windows Description:Lock A row with the option NoWait Details: Hello, I would like to know how to make a lock on a row with the instruction NoWait. Because it is not possible with Select For Update which don't allow NoWait Behind ! Also if it is not possible to do this thing, could it be develloped in a next version ? This will be a new feature in 8.1. See the 8.1 release notes: http://candle.pha.pa.us/main/writings/pgsql/sgml/release.html ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
