Hi Igor,
Thanks for your information.
I was aware of the signal problems and i've done it with thread based
signals
This part is functional on my platform but it isn't fully cooked.
Another problem
is to make this part portable.
Your assumption to replace SysV semaphores with POSIX semaphores
On Tue, 2002-06-11 at 18:36, Josh Berkus wrote:
Karel,
The to_interval() will have another (you wanted) behaviour.
Please, please, please do not use to_interval for text formatting of
intervals.
If he meant what _I_ described then this was exactly that, i.e.
converting
Tatsuo Ishii wrote:
There are full width alphabets in Japanese. Thoes include not only
ASCII letters but also some European characters.
Are these ASCII and European characters uppercased in some
Japanese-specific way ?
Probably not, but I'm not sure since my Linux
On Tue, Jun 11, 2002 at 06:58:54AM -0400, Bruce Momjian wrote:
Wow, how did that A get into the query string:
Buffer overrun. :-(
I just committed Lee's patch. Thanks a lot.
BTW. I didn't even know that this bug was reported against ecpg. Somehow
I missed it. I guess I need to rescan the bug
On Mon, Jun 10, 2002 at 08:09:57PM -, vikas p verma wrote:
this question of mine. I want to insert/update records into the
postgres database through C or perl code. The only condition is
that it should be efficient. Can anybody tell me the difference
between ecpg and libpq and which
On Mon, Jun 10, 2002 at 02:08:22PM -0700, Dann Corbit wrote:
ECPG is single threading. Hence, tools written in ECPG are a pain in
the neck if you want multiple threads of execution. I recommend against
Did he say he wants to write a multi-threaded app?
using it for any purpose except
Good points; not sure why I didn't pick up on this too.
I should point out that I've seen code with heavy Oracle-isms brought
into PostgreSQL using ecpg with amazingly few changes. It is a great
piece of code; any large complaints should perhaps be directed at the
SQL standards themselves...
Hi,
there were several people at my talk asking if PostgreSQL is available
on Novell Netware. I know I read about someone working on this, but
didn't follow the thread at all since I do not have any Netware servers.
Does anyone out there know more?
Thanks in advance.
Michael
--
Michael
David Ford [EMAIL PROTECTED] writes:
So reentrancy in libpq basically is put on hold until 7.3.
Only if you insist on using crypt, which is deprecated anyway.
md5 is the preferred encryption method.
My feeling about the proposed patch was that crypt is now a legacy auth
method, and it's not
-Original Message-
From: Michael Meskes [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 12, 2002 5:41 AM
To: Dann Corbit
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] PostGres Doubt
On Mon, Jun 10, 2002 at 02:08:22PM -0700, Dann Corbit wrote:
ECPG is single threading. Hence,
Michael Meskes wrote:
Hi,
there were several people at my talk asking if PostgreSQL is available
on Novell Netware. I know I read about someone working on this, but
didn't follow the thread at all since I do not have any Netware servers.
Attached is an email message from someone who is
I should apologize for being rather harsh about embedded SQL for
PostgreSQL.
To be fair, it does function and it certainly isn't trivial to
implement. I am sure that those who have worked on this project have
invested very many hours of blood, sweat and tears making it work.
I actually spent a
Do we need to do any more work to document this problem?
---
Tatsuo Ishii wrote:
Oops. How about:
foo'; DROP TABLE t1; -- foo
The last ' gets removed, leaving -- (81a2).
So you get:
select ...
Tom Lane wrote:
I said:
Sorry, you used up your chance at claiming that t_hoff is dispensable.
If we apply your already-submitted patch, it isn't.
Wait, I take that back. t_hoff is important to distinguish how much
bitmap padding there is on a particular tuple --- but that's really
I think libpqxx, the alternative to libpq++, is just about ready for
prime time. That means integrating it with the main source tree, I
suppose, but I have no idea where to start--particularly because libpqxx
has its own configure setup.
Anyone who can help me with this?
Jeroen
PS: find
Deletion of data from a PostgreSQL table is very slow.
It would be nice to have a very fast delete like truncate table.
Now, truncate is a very dangerous command because it is not logged (but
the same is true for other operations like bulk copy and select into).
So one needs to be careful how
Deletion of data from a PostgreSQL table is very slow.
It would be nice to have a very fast delete like truncate table.
Now, truncate is a very dangerous command because it is not logged (but
the same is true for other operations like bulk copy and select into).
So one needs to
...
I would assume that they would use their brain.
Way uncalled for. You must have some other underlying issues to get this
bad 'tude, but please note that ad hominum attacks are *never* welcome
on this or any other PostgreSQL mailing list.
Regards.
- Thomas
On Wed, 2002-06-12 at 14:32, Dann Corbit wrote:
Deletion of data from a PostgreSQL table is very slow.
It would be nice to have a very fast delete like truncate table.
Now, truncate is a very dangerous command because it is not logged (but
the same is true for other operations like bulk
-Original Message-
From: Larry Rosenman [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 12, 2002 12:36 PM
To: Dann Corbit
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Feature request: Truncate table
On Wed, 2002-06-12 at 14:32, Dann Corbit wrote:
Deletion of data from a
On Wed, 2002-06-12 at 13:37, Billy O'Connor wrote:
Deletion of data from a PostgreSQL table is very slow.
It would be nice to have a very fast delete like truncate table.
Now, truncate is a very dangerous command because it is not logged (but
the same is true for other
On Wed, 12 Jun 2002 20:29:21 +0200
Jeroen T. Vermeulen [EMAIL PROTECTED] wrote:
I think libpqxx, the alternative to libpq++, is just about ready for
prime time.
Great -- I like libpqxx a lot, and I'd like to see it in 7.3. We should
also probably keep libpq++ around for backward compatibility,
On Wed, Jun 12, 2002 at 04:04:36PM -0400, Neil Conway wrote:
Otherwise, if you put the code into src/interfaces/libpqxx and modify
the PostgreSQL build system to be aware of it (as well as removing
libpqxx's autoconf stuff), it shouldn't be too difficult.
One concern I have on this point is
I am not sure that this has enough general interest to be included in
our code. If you make a loadable module, we can add it to our web site.
---
Alex Shevlakov wrote:
New 'path' functions (test results can be found at
Dann Corbit wrote:
-Original Message-
From: Michael Meskes [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 12, 2002 5:41 AM
To: Dann Corbit
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] PostGres Doubt
On Mon, Jun 10, 2002 at 02:08:22PM -0700, Dann Corbit wrote:
ECPG
Well in Ingres there is a WORLD of difference! For a start, you don't
lock out the system catalog. Secondly it is an unlogged event, so it
beats delete from table_name hands down! Then, of course, it preserves
all permissions, you keep the same OID, so views, et al, can remain in
tact, as
Dann Corbit wrote:
I should apologize for being rather harsh about embedded SQL for
PostgreSQL.
To be fair, it does function and it certainly isn't trivial to
implement. I am sure that those who have worked on this project have
invested very many hours of blood, sweat and tears making it
Jeroen T. Vermeulen wrote:
On Wed, Jun 12, 2002 at 04:04:36PM -0400, Neil Conway wrote:
Otherwise, if you put the code into src/interfaces/libpqxx and modify
the PostgreSQL build system to be aware of it (as well as removing
libpqxx's autoconf stuff), it shouldn't be too difficult.
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 12, 2002 2:42 PM
To: Dann Corbit
Cc: Michael Meskes; [EMAIL PROTECTED]
Subject: Re: [HACKERS] PostGres Doubt
Dann Corbit wrote:
I should apologize for being rather harsh about embedded SQL
Dann Corbit
I assume this is because you wrote your code assuming a feature was in
ecpg, but it wasn't, right?
I have written lots of programs that use embedded SQL. I have (for
instance) several ODBC drivers that use embedded SQL and C++ as part of
an ODBC driver system. I merrily
On Wed, Jun 12, 2002 at 05:48:46PM -0400, Bruce Momjian wrote:
I can add it to CVS as interfaces/libpqxx and we can then let others
merge your configure tests into our main configure. Let me know when
you want it dumped into CVS.
Might as well do it right now, with 0.5.2. We'll call that
Bradley Kieser wrote:
Well in Ingres there is a WORLD of difference! For a start, you don't
lock out the system catalog. Secondly it is an unlogged event, so it
beats delete from table_name hands down! Then, of course, it preserves
all permissions, you keep the same OID, so views, et al,
Jeroen T. Vermeulen wrote:
On Wed, Jun 12, 2002 at 05:48:46PM -0400, Bruce Momjian wrote:
I can add it to CVS as interfaces/libpqxx and we can then let others
merge your configure tests into our main configure. Let me know when
you want it dumped into CVS.
Might as well do it right
Thomas Lockhart wrote:
Right. I'm not certain about the regex syntax defined by SQL99; I used
the syntax that we already have enabled and it looks like we have a
couple of other variants available if we need them. If someone wants to
research the *actual* syntax specified by SQL99 that would
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 12, 2002 3:20 PM
To: Dann Corbit
Cc: Michael Meskes; [EMAIL PROTECTED]
Subject: Re: [HACKERS] PostGres Doubt
Dann Corbit
I assume this is because you wrote your code assuming a
feature
Dann Corbit wrote:
So now, I started getting down to the details. One global
structure...
I started a major rewrite to repair it. Then (to my abject
horror) I
discovered there is no SQLCA at all. Project abandoned
(actually, just
switched to libpq and everything was OK).
On Wed, 2002-06-12 at 17:30, Bruce Momjian wrote:
Jeroen T. Vermeulen wrote:
On Wed, Jun 12, 2002 at 05:48:46PM -0400, Bruce Momjian wrote:
I can add it to CVS as interfaces/libpqxx and we can then let others
merge your configure tests into our main configure. Let me know when
Larry Rosenman wrote:
I think we will just give you CVS access. Not sure how to get the CVS
history. I think if you send me the CVS root I can use CVS import to
load it.
If you Repocopy the files, the history will stay intact. Basically
move his CVS/ files to your repository, and
On Wed, 2002-06-12 at 19:41, Bruce Momjian wrote:
Larry Rosenman wrote:
I think we will just give you CVS access. Not sure how to get the CVS
history. I think if you send me the CVS root I can use CVS import to
load it.
If you Repocopy the files, the history will stay intact.
Do we need to do any more work to document this problem?
Better documetation will be welcome. However which document?
--
Tatsuo Ishii
---
Tatsuo Ishii wrote:
Oops. How about:
foo'; DROP TABLE t1; -- foo
What is a TRUNCATE TABLE but a drop create anyway? Is there some
technical difference?
It doesn't kill indexes/triggers/constraints/Foreign Key Stuff, etc.
Hrm - last time I checked it did...
Chris
---(end of broadcast)---
TIP 1:
On Wed, 2002-06-12 at 19:41, Bruce Momjian wrote:
Ewe, appropriate entries?
I'm thinking we should just import the current state of the files
and not worry about preserving their change history.
regards, tom lane
---(end of
Just so you know, current CVS HEAD passes all tests on FreeBSD/Alpha (a
64bit machine) with this configure:
./configure --prefix=/home/chriskl/local --enable-integer-datetimes --enable
-debug --enable-depend --enable-cassert --with-pam --with-openssl --with-CXX
Chris
Since we just had the discussion about index size, I have written a
section for our administration manual that shows ways of finding the
disk usage for specific tables and databases:
http://candle.pha.pa.us/main/writings/pgsql/sgml/diskusage.html
I also updated README.oid2name to show a
44 matches
Mail list logo
