Re: [HACKERS] xeon processors

2004-06-26 Thread Alvaro Herrera
On Sat, Jun 26, 2004 at 07:31:59PM -0600, Scott Marlowe wrote: > On Fri, 2004-06-25 at 14:13, Jaime Casanova wrote: > > Hi all, > > > > Can anyone tell me if postgresql has problems with xeon processors? > > If so, there is any fix or project of fix it? > > To PostgreSQL, there's no difference

Re: [HACKERS] recursive SQL

2004-06-26 Thread Tom Lane
"jacob koehler (RRes-Roth)" <[EMAIL PROTECTED]> writes: >> It would first have to be relicensed ... > it would be interesting to know if it would be included, IFF the author > publishes it under BSD. This patch has been proposed and rejected before. It doesn't do the SQL-standard syntax for recu

Re: [HACKERS] recursive SQL

2004-06-26 Thread Christopher Kings-Lynne
- Evgen DID publish this patch under GPL, see: http://gppl.terminal.ru/README.html We cannot use GPL code in PostgreSQL. PostgreSQL is BSD licensed. As to why on earth he GPL'd - I have no idea... Chris ---(end of broadcast)--- TIP 1: subscribe an

Re: [HACKERS] [DEFAULT] Daily digest v1.4537 (18 messages)

2004-06-26 Thread Josh Berkus
Jacob, > cons: > - its not standard SQL (uses oracle style syntax) Which is, plain and simple, a deal-breaker. You can count on me to vote against inclusion of any patch which uses non-standard SQL when a standard syntax is available. Further, the IS_CONNECTED_BY() function is available in /

Re: [HACKERS] xeon processors

2004-06-26 Thread Scott Marlowe
On Fri, 2004-06-25 at 14:13, Jaime Casanova wrote: > Hi all, > > Can anyone tell me if postgresql has problems with xeon processors? > If so, there is any fix or project of fix it? To PostgreSQL, there's no difference between a dual CPU machine with no hyperthreading, and a single CPU machine

Re: [HACKERS] recursive SQL

2004-06-26 Thread jacob koehler (RRes-Roth)
> -Original Message- > From: Andrew Dunstan [mailto:[EMAIL PROTECTED] > Sent: 26 June 2004 20:42 > To: [EMAIL PROTECTED] > Subject: Re: [HACKERS] recursive SQL > > > > > jacob koehler (RRes-Roth) wrote: > > >hi, > > > >i am wondering what you think about including evgen potemkin's p

Re: [HACKERS] recursive SQL

2004-06-26 Thread Andrew Dunstan
jacob koehler (RRes-Roth) wrote: hi, i am wondering what you think about including evgen potemkin's patch for recursive SQL in the next postgres version: http://gppl.terminal.ru/ [snip] - Evgen DID publish this patch under GPL, see: http://gppl.terminal.ru/README.html It would first have to b

[HACKERS] recursive SQL

2004-06-26 Thread jacob koehler (RRes-Roth)
hi, i am wondering what you think about including evgen potemkin's patch for recursive SQL in the next postgres version: http://gppl.terminal.ru/ cons: - its not standard SQL (uses oracle style syntax) pros: - it would add a feature that many people miss already for ages. all existing workarou

Re: [HACKERS] [PATCHES] nested xacts and phantom Xids

2004-06-26 Thread Greg Stark
Alvaro Herrera <[EMAIL PROTECTED]> writes: > It has been suggested a couple of times that we should use a different > syntax for subtransactions than for main transactions. This would for > example allow things like > > > BEGIN; > do something; > SUBBEGIN; It might be awkward for

Re: [HACKERS] PREPARE and transactions

2004-06-26 Thread Alvaro Herrera
On Sat, Jun 26, 2004 at 09:12:33AM -0400, Merlin Moncure wrote: > > BEGIN; > > ... do something ... ; > > SUBBEGIN; > > EXECUTE ...; > > -- if it fails: > > -- SUBABORT; > > -- PREPARE ...; > > -- SUBBEGIN; > > -- EXEC

Re: [HACKERS] warning missing

2004-06-26 Thread Thomas Hallgren
Gaetano, I've been using C++ for 15 years and Java for 7. I like them both. Every language has its pros and cons. C++ can be extremely powerful in the hands of someone who knows how to use it. I actually wrote the first version of Pl/Java in C++. However, I got strong advice to rewrite it using p

Re: [HACKERS] PREPARE and transactions

2004-06-26 Thread Merlin Moncure
> > I would be fine with changing the lifetime if an EXECUTE failure did not > > abort the current transaction. Then I could simply watch the return > > code of the statement execution and prepare the statement on > > demand...from my point of view, this would actually be the most elegant > > scen