Re: [HACKERS] NOTICE vs WARNING

Peter Eisentraut <[EMAIL PROTECTED]> writes: > Well, there are plenty of NOTICE instances that carry a definite need to > worry, such as identifier truncation, implicitly added FROM items, > implicit changes to types specified as "opaque", unsupported and ignored > syntax clauses. Of course, some

[HACKERS] 2-phase commit

Hi, As the 7.4 beta rolls on, I thought now would be a good time to start talking about the future. I have a potential need in the future for distributed transactions (XA). To get that from Postgres, I'd need two-phase commit, I think. There is someone working on such a project (

Re: [HACKERS] Networking in 7.4?

Tom Lane wrote: > Josh Berkus <[EMAIL PROTECTED]> writes: > > Do we have full Rendezvous and IPv6 support in 7.4? That is, sufficient to > > shout about in our PR materials? > > The IPv6 support does everything you could want AFAIK, and is certainly > worth a bullet point. > > I'm not sure how

Re: [HACKERS] NOTICE vs WARNING

Christopher Kings-Lynne writes: > Surely a WARNING is a problem that you should probably fix? How are "should" and "probably" defined? > Or at least pay attention to. If it were in fact the characteristic of a NOTICE that you need not pay attention to them, why do we have them? > My thought is

Re: [HACKERS] Decent VACUUM (was: Buglist)

On Thu, 21 Aug 2003, Tom Lane wrote: > We have had some people looking at improved buffer management > algorithms; LRU-2 or something smarter would help. I dunno whether > we can dissuade the kernel from flushing its cache though. Using open/read/write system calls, you can't. You can always use

[HACKERS] WHERE order

It would appear that in 7.4 the order of clauses in WHERE affects the execution time (not output if AND). I would think that a simple optimization would be to push off evaluation of a subplan whenever possible by re-arranging AND statements. In the below example, it gives an order of magnitude sp

Re: [HACKERS] table-level and row-level locks.

if table and page are locked in src/backend/storage/lmgr/lmgr.c by LockRelation() and LockPage respectively, in which file and by which function is a row locked? thanks Jenny From: "Jenny -" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [HACKERS] table-level and row-level locks. Date:

Re: [HACKERS] Date input changed in 7.4 ?

How about reporting the current DateStyle in such messages? Then it should be clear if the date parse failed because of a mismatch. andrew Tom Lane wrote: "Mendola Gaetano" <[EMAIL PROTECTED]> writes: May I also suggest to change in date.c the 3 generic error: "invalid input syntax for da

Re: [HACKERS] Date input changed in 7.4 ?

"Mendola Gaetano" <[EMAIL PROTECTED]> writes: > May I also suggest to change in date.c the 3 generic error: > "invalid input syntax for date: " > with more comprensive messages ? That's easier said than done; there are enough different valid syntaxes that it's not always obvious what the user'

[HACKERS] row level locks

How do we acquire row level locks in postgresql and is there any feild in LOCK or PROCLOCK datastructes (src/include/storage/lock.h) that tells us the lock is row-level? thanks _ Enter for your chance to IM with Bon Jovi, Seal, Bow

Re: [HACKERS] Date input changed in 7.4 ?

"Tom Lane" <[EMAIL PROTECTED]> wrote: > "Mendola Gaetano" <[EMAIL PROTECTED]> writes: > > I noticed that some date are not anymore accepted: > > test=# select '18/03/71'::date; > > ERROR: invalid input syntax for date: "18/03/71" > > is this the indendeed behaviour ? > > If it does not match your

Re: [HACKERS] Date input changed in 7.4 ?

"Bruce Momjian" <[EMAIL PROTECTED]> wrote: > Mendola Gaetano wrote: > > Hi all, > > I noticed that some date are not anymore accepted: > > > > > > Postgres 7.3.3: > > > > test=# select '18/03/71'::date; > > date > > > > 1971-03-18 > > (1 row) > > > > > > Postgres 7.4beta1

Re: [HACKERS] Date input changed in 7.4 ?

"Mendola Gaetano" <[EMAIL PROTECTED]> writes: > I noticed that some date are not anymore accepted: > test=# select '18/03/71'::date; > ERROR: invalid input syntax for date: "18/03/71" > is this the indendeed behaviour ? If it does not match your DateStyle setting, then yes. regression=# select '

Re: [HACKERS] Date input changed in 7.4 ?

Mendola Gaetano wrote: > Hi all, > I noticed that some date are not anymore accepted: > > > Postgres 7.3.3: > > test=# select '18/03/71'::date; > date > > 1971-03-18 > (1 row) > > > Postgres 7.4beta1: > > test=# select '18/03/71'::date; > ERROR: invalid input syntax for

[HACKERS] Date input changed in 7.4 ?

Hi all, I noticed that some date are not anymore accepted: Postgres 7.3.3: test=# select '18/03/71'::date; date 1971-03-18 (1 row) Postgres 7.4beta1: test=# select '18/03/71'::date; ERROR: invalid input syntax for date: "18/03/71" is this the indendeed behaviour ? Re

Re: [HACKERS] [BUGS] postgresql 7.3.2 bug on date '1901-12-13' and '1901-12

Stephan Szabo <[EMAIL PROTECTED]> writes: > On Thu, 21 Aug 2003, Tom Lane wrote: >> Stephan Szabo <[EMAIL PROTECTED]> writes: >>> Wait, he's in australia, what if he's getting the edge case the other way. >> >> I'm inclined to fix to_date by decomposing the code differently --- >> it should avoid

Re: [HACKERS] NOTICE vs WARNING

Peter Eisentraut <[EMAIL PROTECTED]> writes: > Can someone explain in succinct and general terms what the difference > between a NOTICE and a WARNING is? I'm currently examining the validity > of notice and warning messages throughout the backend, but I find these > categories to be applied incons

Re: [HACKERS] [BUGS] postgresql 7.3.2 bug on date '1901-12-13' and '1901-12

On Mon, 25 Aug 2003, Tom Lane wrote: > Stephan Szabo <[EMAIL PROTECTED]> writes: > > On Thu, 21 Aug 2003, Tom Lane wrote: > >> Stephan Szabo <[EMAIL PROTECTED]> writes: > >>> Wait, he's in australia, what if he's getting the edge case the other way. > >> > >> I'm inclined to fix to_date by decompo

[HACKERS] Need Documentation(information) about PostgreSql's structure

Help me, please. I need to add any funtions to PostgreSql's source v. 7.32. It is too hard for a newbie himself to know what each function does. I try to understand PostgreSql structure through readme files, postgres tutorial and commentaries in postgresql source but along time i can't unders

Re: [HACKERS] I am back

> > That really should be up to you. Conferences are a great way to lift the > > project's profile, and PostgreSQL talks are very popular and well > > attended. However, as your email seems to suggest, they're pretty time > > consuming and generally pretty far away from home. I was definitely > > f

Re: [HACKERS] NOTICE vs WARNING

Surely a WARNING is a problem that you should probably fix? Or at least pay attention to. My thought is that you could turn of NOTICES and not worry. (Which is what I sometimes do during restore, etc.) Chris - Original Message - From: "Peter Eisentraut" <[EMAIL PROTECTED]> To: "Postgre

Re: [HACKERS] set constraints docs page

Kevin Brown wrote: > Tom Lane wrote: > > "Andrew Dunstan" <[EMAIL PROTECTED]> writes: > > >> I object to creating gratuitous incompatibilities with the SQL standard, > > >> which will obstruct legitimate features down the road. The SQL standard > > >> says it is .. > > > > > Is there a case for e

Re: [HACKERS] backwards-compat problem?

Got it. --- Tom Lane wrote: > "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > > Can we ensue that this is listed in the release notes clearly then? > > Bruce hasn't made up the "incompatibilities to note" section ye