I see there is a cvs directory for this, what happened to the contents?
Or do we just get this from apache?
Dave
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
test_thread.pgc:51: undefined reference to `pthread_create'
undefined reference to `pthread_join'
Dave
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not
On Thursday 18 December 2003 17:37, Dave Cramer wrote:
test_thread.pgc:51: undefined reference to `pthread_create'
undefined reference to `pthread_join'
It is not linking against pthreads library. Do you have -lpthread cause in
your compilation/linking command?
Shridhar
Shridhar,
Obviously not, but I just did make inside the test directory, so I
assume the Makefile needs to be fixed.
Thanks,
Dave
On Thu, 2003-12-18 at 07:21, Shridhar Daithankar wrote:
On Thursday 18 December 2003 17:37, Dave Cramer wrote:
test_thread.pgc:51: undefined reference to
On Thursday 18 December 2003 18:03, Dave Cramer wrote:
Shridhar,
Obviously not, but I just did make inside the test directory, so I
assume the Makefile needs to be fixed.
I don't think so.. Check this..
[EMAIL PROTECTED] pgsql]$ find . -name Makefile.global
./src/Makefile.global
[EMAIL
I find this a little strange:
select date_part('year', '0002-01-01 BC'::date);
date_part
---
-1
It seems 1 BC and 0 are the same year.
In backend/utils/adt/formatting.c:
if (tmfc.bc)
{
if (tm-tm_year 0)
tm-tm_year =
Dave Cramer wrote:
Shridhar,
Obviously not, but I just did make inside the test directory, so I
assume the Makefile needs to be fixed.
Thanks,
Dave
On Thu, 2003-12-18 at 07:21, Shridhar Daithankar wrote:
On Thursday 18 December 2003 17:37, Dave Cramer wrote:
test_thread.pgc:51:
Kurt Roeckx wrote:
I find this a little strange:
select date_part('year', '0002-01-01 BC'::date);
date_part
---
-1
It seems 1 BC and 0 are the same year.
In backend/utils/adt/formatting.c:
if (tmfc.bc)
{
if (tm-tm_year 0)
Yeah...
That would help me s much, that would s cool...
According to what I read on the subject after I got this mail, could we
envison something like:
ALTER DATABASE xxx SET max_connection to 100;
?
Regards
On Wed, 17 Dec 2003, Larry Rosenman wrote:
Date: Wed, 17 Dec 2003 15:13:00
Wasn't there a patch posted many months ago for PITR. IIRC it wasn't
complete, but would be a good starting point for those interested in
helping out. If it's in the archives it would be nice to add a link to
it on the project page... which brings up the question on whats the
process for updating
Hi,
I want to concatenate a it counter to a string in a loop in plpgsql.
DECLARE
counter integer := 1;
IdSet char : = 'UniqueId'
IdForEachRun varchar;
BEGIN
IdForEachRun := IdSet || counter;(PROBLEM HERE)
--Or IdForEachRun := IdSet + counter;(PROBLEM HERE)
While condition LOOP
Insert into Table
On Thursday 18 December 2003 20:16, Robert Treat wrote:
On Wed, 2003-12-17 at 21:37, Bruce Momjian wrote:
I have put up a list of projects being worked on and their TODO lists in
hope that people will find it easier to work on them:
In article [EMAIL PROTECTED] you wrote:
I find this a little strange:
select date_part('year', '0002-01-01 BC'::date);
date_part
---
-1
It seems 1 BC and 0 are the same year.
There is an unresolveable legacy problem here, in that Brahmagupta did
not yet invent the
Is there any good reason for this restriction?
regression=# begin;
BEGIN
regression=# declare c cursor for select * from tenk1 for update;
ERROR: DECLARE CURSOR ... FOR UPDATE is not supported
DETAIL: Cursors must be READ ONLY.
While I have not tried it, I think that simply removing this error
Paul Punett [EMAIL PROTECTED] writes:
Hi,
I want to concatenate a it counter to a string in a loop in plpgsql.
DECLARE
counter integer := 1;
IdSet char : = 'UniqueId'
IdForEachRun varchar;
BEGIN
IdForEachRun := IdSet || counter;(PROBLEM HERE)
IdForEachRun := IdSet || counter::text;
On Thu, 2003-12-18 at 10:20, Tom Lane wrote:
Is there any good reason for this restriction?
regression=# begin;
BEGIN
regression=# declare c cursor for select * from tenk1 for update;
ERROR: DECLARE CURSOR ... FOR UPDATE is not supported
DETAIL: Cursors must be READ ONLY.
While I have
We have a rude hack of temping hashed aggs to disk to deal with the
case where there is not enough memory. I don't think that's an ideal
solution, but it certainly has the code to dump to file. I can post
the patch later in the day ..
(This is some code for our undergrad db class assignment. I
Robert Treat [EMAIL PROTECTED] writes:
Wasn't there a patch posted many months ago for PITR.
I have the latest version of what J.R. and Patrick were working on, and
plan to review and apply it in the next couple weeks. However, my
understanding is that it's just some necessary infrastructure
Bruce,
You are correct. I did not configure with --enable-thread-safety
Dave
On Thu, 2003-12-18 at 08:40, Bruce Momjian wrote:
Dave Cramer wrote:
Shridhar,
Obviously not, but I just did make inside the test directory, so I
assume the Makefile needs to be fixed.
Thanks,
Dave
Rod Taylor [EMAIL PROTECTED] writes:
On Thu, 2003-12-18 at 10:20, Tom Lane wrote:
Is there any good reason for this restriction?
The help implies you can.
DECLARE name [ BINARY ] [ INSENSITIVE ] [ [ NO ] SCROLL ]
CURSOR [ { WITH | WITHOUT } HOLD ] FOR query
[ FOR { READ ONLY |
If people are happy with Tom's suggestion of using '*' instead of 'all'
in pg_hba.conf I will prepare a patch for it.
(I will also replace the ugly long IP6 localhost netmask with a CIDR mask).
cheers
andrew
---(end of broadcast)---
TIP 2: you
Andrew Dunstan wrote:
If people are happy with Tom's suggestion of using '*' instead of
'all' in pg_hba.conf I will prepare a patch for it.
Well, while we're breaking stuff in the name of improvement, what about
databases named * or databases with spaces in their names?
Tom Lane wrote:
Hm. I'm of the opinion that the real problem here is the code's
assumption that it is reasonable to force dbname = servicename when
the service file doesn't say any such thing. For all other
parameters, omitting the parameter from pg_service.conf causes the
standard default
Peter Eisentraut [EMAIL PROTECTED] writes:
Regardless of this particular issue, I think it would be useful if,
under some conditions to be identified, some service were taken as
default if nothing is specied in libpq. That would eliminate the need
to set environment variables, which is
Peter Eisentraut wrote:
Andrew Dunstan wrote:
If people are happy with Tom's suggestion of using '*' instead of
'all' in pg_hba.conf I will prepare a patch for it.
Well, while we're breaking stuff in the name of improvement, what about
databases named * or databases with spaces in their
How about the typical answer on Windows ? Create an invisible Window
with an Event Handler and pass it a windows message ?
Andreas
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister
Does anyone know how Informix, where this file comes from,
handles this?
Informix puts those files in $INFORMIXDIR/incl/esql (e.g. /usr/informix/incl/esql),
so imho a /usr/postgres installation could have them somewhere under /usr/postgres
Andreas
---(end of
Michael Meskes wrote:
On Wed, Dec 17, 2003 at 10:27:19AM -0500, Bruce Momjian wrote:
Are you suggesting moving the ecpg files into pgsql/include/ecpg?
Do we know that no one using ecpg is going to be including a
/usr/include file that needs /usr/include/xxx.h?
No, just the files needed
I wrote:
Peter Eisentraut wrote:
Andrew Dunstan wrote:
If people are happy with Tom's suggestion of using '*' instead of
'all' in pg_hba.conf I will prepare a patch for it.
Well, while we're breaking stuff in the name of improvement, what
about databases named * or databases with spaces
On Thu, 18 Dec 2003, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
On Thu, 2003-12-18 at 10:20, Tom Lane wrote:
Is there any good reason for this restriction?
The help implies you can.
DECLARE name [ BINARY ] [ INSENSITIVE ] [ [ NO ] SCROLL ]
CURSOR [ { WITH | WITHOUT }
For those working on search features, here's a new collection of essays
on full text indexing mentioned on slashdot:
http://www.tbray.org/ongoing/When/200x/2003/07/30/OnSearchTOC
Chris
---(end of broadcast)---
TIP 2: you can get off all lists at
Andrew Dunstan [EMAIL PROTECTED] writes:
The minimal disturbance change might be to teach the parser to
distinguish between a quoted 'all' and an unquoted 'all', and forget the
'*' idea.
Probably we ought to go with that, on backwards-compatibility grounds.
regards,
Hello, can you please tell me how to return a NULL value
from a function? I am running postgresql 7.3.2. and the
following is my case. Thank you very much.
Chongbing
header file ===
#include postgres.h
#include fmgr.h
#include string.h
#include sys/types.h
#ifndef
33 matches
Mail list logo
