[HACKERS] How can I return a NULL value from a function?
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
#include
#ifndef pname_h
#define pname_h 1
struct pname
{
int size;
char name[1];
};
typedef struct pname pname;
pname * pname_in( char * in);
char * pname_out( pname * nm);
#endif
C code =
#include "postgres.h"
#include "fmgr.h"
#include "pname.h"
#include
#include
#ifndef pname_c
#define pname_c 1
pname * pname_in(char * in) {
int i;
pname * n;
n = (pname *) palloc(strlen(in)+VARHDRSZ);
n->size=strlen(in)+VARHDRSZ;
memcpy(n->name, in, strlen(in));
if(strlen(in)<4)
return (NULL);
return n;
}
char * pname_out(pname* nm) {
char *t;
if(nm==NULL)
return (NULL);
t = (char *) palloc(VARSIZE(nm)-VARHDRSZ+1);
strcpy(t,nm->name);
return t;
}
#endif
== psql command for function installation =
CREATE FUNCTION pname_in (opaque)
RETURNS pname
AS '/home/cliu/types_lib/pname.so', 'pname_in'
LANGUAGE 'c';
CREATE FUNCTION pname_out(opaque)
RETURNS opaque
AS '/home/cliu/types_lib/pname.so','pname_out'
LANGUAGE 'c';
CREATE TYPE pname (
input = pname_in,
output = pname_out,
internallength = VARIABLE,
externallength = VARIABLE,
default = " "
);
== test cases ===
cliu=# select pname('abcdefghijk');
NOTICE: ok2:abcdefghijk
pname
-
abcdefghijk
(1 row)
cliu=# select pname('ab');
NOTICE: ok2:ab
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!#
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] replace all with * in pg_hba.conf
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, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Full text search reference
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 once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Why isn't DECLARE CURSOR ... FOR UPDATE supported?
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 } HOLD ] FOR query
> > [ FOR { READ ONLY | UPDATE [ OF column [, ...] ] } ]
>
> Hmm. Actually that is describing the SQL spec's syntax for DECLARE
> CURSOR, in which you can name specific *columns* not tables as being
> updatable through the cursor. Now that I think about it, the error
> check is probably there to catch anyone who writes "FOR UPDATE OF
> column" expecting to get the SQL spec behavior.
>
> I'm not sure whether anyone is planning to try to converge our notion of
> FOR UPDATE with the spec's. If that is going to happen someday, it'd
> probably be best not to introduce directly conflicting behavior into
> DECLARE CURSOR. Oh well...
I was going to look at it for 7.5. However, we don't have column locks
:-(.
Thanks,
Gavin
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] replace all with * in pg_hba.conf
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 in their names? Good point. Perhaps we need to provide for an escaping mechanism in the routines that parse the file, although personally I have little sympathy for anyone who names a database '*'. I think it comes into the category of "Doctor, it hurts when I do this" ... "Then stop doing that." Spaces are a more likely problem, especially when we get W32 native users. Looking at the code I discover that there is already provision covering spaces etc., because you can quote names. It's even documented ;-) The minimal disturbance change might be to teach the parser to distinguish between a quoted 'all' and an unquoted 'all', and forget the '*' idea. Alternatively, do the same sort of thing, but replacing 'all' with '*'. A patch for the first would be quite tiny - similar for '*' except for extra doc and sample file changes. cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.4 include file conflict
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 for Informix compatibility. Peter is > preparing a patch that dave can test for us, so we hopefully get this > into CVS until Friday. Patch installed. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 7.4 include file conflict
> 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 broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-hackers-win32] [HACKERS] [PATCHES] fork/exec patch
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 YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] replace all with * in pg_hba.conf
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 names? Good point. Perhaps we need to provide for an escaping mechanism in the routines that parse the file, although personally I have little sympathy for anyone who names a database '*'. I think it comes into the category of "Doctor, it hurts when I do this" ... "Then stop doing that." Spaces are a more likely problem, especially when we get W32 native users. cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [BUGS] pg_service.conf ignores dbname parameter
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 undesirable in many situations. That's a thought. Maybe if pg_service.conf exists and contains a section named "default", we use whatever settings are present there? (Obviously we'd not want the dbname to be forced by this, but I think we've already agreed to get rid of that behavior.) About the only downside I can see to this is that every connection would incur the overhead of an attempted file opening. That might be thought to be too much overhead, at least by people who have no use for the feature. But in comparison to what will happen on the server side during backend startup, it's probably pretty negligible. BTW, why is it that pg_service.conf is system-wide? Personally I'd think it more useful to seek settings in ~/.pg_service.conf. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [BUGS] pg_service.conf ignores dbname parameter
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 to be adopted. Why should dbname work differently? 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 undesirable in many situations. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] replace all with * in pg_hba.conf
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? ---(end of broadcast)--- TIP 3: 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
[HACKERS] replace all with * in pg_hba.conf
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 can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Why isn't DECLARE CURSOR ... FOR UPDATE supported?
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 | UPDATE [ OF column [, ...] ] } ]
Hmm. Actually that is describing the SQL spec's syntax for DECLARE
CURSOR, in which you can name specific *columns* not tables as being
updatable through the cursor. Now that I think about it, the error
check is probably there to catch anyone who writes "FOR UPDATE OF
column" expecting to get the SQL spec behavior.
I'm not sure whether anyone is planning to try to converge our notion of
FOR UPDATE with the spec's. If that is going to happen someday, it'd
probably be best not to introduce directly conflicting behavior into
DECLARE CURSOR. Oh well...
regards, tom lane
---(end of broadcast)---
TIP 3: 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: [HACKERS] ecpg tests compile failure
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 > > > > 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 `pthread_create' > > > > undefined reference to `pthread_join' > > > > > > It is not linking against pthreads library. Do you have -lpthread cause in > > > your compilation/linking command? > > The ecpg/test/Makefile has: > > override CPPFLAGS := -I$(srcdir)/../include -I$(libpq_srcdir) $(CPPFLAGS) > $(THREAD_CPPFLAGS) > > and > %: %.o > $(CC) $(CFLAGS) $(LDFLAGS) -L../ecpglib -L ../pgtypeslib -L../../libpq > $^ $(LIBS) -lpgtypes > -lecpg -lpq $(THREAD_LIBS) -o $@ > > so I see the thread compile and link flags mentioned in the Makefile. > My guess is that you didn't compile the backend with > --enable-thread-safety. I wonder if I should disable the thread ecpg > test program when this compile option is not used. Is that correct? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Project status pages
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 (improvement of the WAL file format) and doesn't make any real progress in terms of creating user-accessible functionality. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] OLAP CUBE/ROLLUP Operators and GROUP BY grouping sets
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 was planning to clean it up and submit it properly but I never got the time) -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Why isn't DECLARE CURSOR ... FOR UPDATE supported?
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 not tried it, I think that simply removing this error check
> in PerformCursorOpen() would allow the system to behave in a reasonable
> way, ie, locking each row the first time it is fetched through the
> cursor.
The help implies you can.
Command: DECLARE
Description: define a cursor
Syntax:
DECLARE name [ BINARY ] [ INSENSITIVE ] [ [ NO ] SCROLL ]
CURSOR [ { WITH | WITHOUT } HOLD ] FOR query
[ FOR { READ ONLY | UPDATE [ OF column [, ...] ] } ]
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] plpgsql Integer Concat To String
"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; -Doug ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Why isn't DECLARE CURSOR ... FOR UPDATE supported?
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 check in PerformCursorOpen() would allow the system to behave in a reasonable way, ie, locking each row the first time it is fetched through the cursor. A recent conversation on pgsql-bugs led me to think of this as an easy way to get the effect of "LIMIT after FOR UPDATE" --- that is, you declare the cursor as above and then FETCH just one row, or however many you need. With the current implementation in which LIMIT acts before FOR UPDATE, it's possible the "SELECT ... LIMIT 1 FOR UPDATE" will return no row, even though lockable rows exist in the table. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Dates BC.
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 mathematical concept of 0 until ~ 598 CE, by which
time the Roman Empire had fallen (depending on whether you believe it
actually fell). We'll just have to live with some weirdness on this
one. :)
Cheers,
D
--
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 510 893 6100cell: +1 415 235 3778
This is my .sig. There are many like it, but this one is mine.
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] Project status pages
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:
> >
> > http://momjian.postgresql.org/main/writings/pgsql/project
Browsing that page I noticed tablespaces item. I have this file we have
prepared long time back. I think it deserves a mention on that page.
May be I should edit it to completion and then send. But this is for review
for others so that any bugs are ironed out..
Shridhar
POSTGRESQL LOCATIONS DESIGN DOCUMENT
Authors:
Christopher Kings-Lynne ([EMAIL PROTECTED])
Writtem:
30th June 2003
Version:
0.1
REQUIREMENTS
1. To be able to specify the physical location of tables and indexes
from within the PostgreSQL SQL environment.
2. Databases and schemas will be able to have a default table and
default index location specified. Unless overridden at creation
time, a new object will inherit its location from, first, its
schema and second, its database. ** Is a default temporary
tablespace required?
3. At creation time of all tables and indexes, it should be possible
to specify a location. This includes UNIQUE and PRIMARY KEY
declarations.
4. We should allow anonymous locations wherever we allow a .
This means that PsotgreSQL will create a new location on the fly,
with a generated name. This could help with backward compatibility
with the CREATE DATABASE location clause.
5. If you don't like 'location', then s/location/storage/g.
CATALOG CHANGES
---
A new (global) catalog will need to be created, pg_location.
It will need to have the following fields:
locoid OID UNIQUE NOT NULLLocation identifier
locname TEXTUNIQUE NOT NULLLocation name
locpath TEXTNOT NULLLocation path (eg. /spaces/ind1)
locconfig TEXT[] GUC variables for objects
in this location.
locacl ACLITEM[] Access controls for location.
New fields will be required in pg_database:
datrellocid OID Default table
location identifier
datindlocid OID Default index
location identifier
New fields will be required in pg_namespace:
nsprellocid OID Default table
location identifier
nspindlocid OID Default index
location identifier
The default location fields above can be NULL, in which case objects
default to datpath for the database.
*** Should we just remove datpath and make datrellocid NOT NULL???
PERMISSIONS
---
Locations will have a single permission - USAGE. By default, the creator of a
tablespace will be its owner and will have USAGE rights.
Locations can only be created and altered by a superuser.
GRAMMAR
---
For direct manipulation of locations:
CREATE LOCATION AS '';
DROP LOCATION [ CASCADE | RESTRICT ];
ALTER LOCATION SET { TO | = } { | DEFAULT };
ALTER LOCATION RESET ;
ALTER LOCATION RENAME TO ;
For the specification of default locations:
CREATE DATABASE [ WITH ] { TABLE | INDEX } LOCATION ;
ALTER DATABASE { TABLE | INDEX } LOCATION { | DEFAULT };
*** How do we handle existing LOCATION clause?
CREATE SCHEMA { TABLE | INDEX } LOCATION ;
ALTER SCHEMA { TABLE | INDEX } LOCATION { | DEFAULT };
Object creation:
CREATE TABLE ... ( ... PRIMARY KEY LOCATION , UNIQUE LOCATION ... )
... LOCATION ;
CREATE INDEX ... LOCATION ;
ALTER TABLE ... ADD { UNIQUE | PRIMARY KEY } ... LOCATION ;
DIAGNOSTICS
---
These are the result strings for location manipulation:
CREATE LOCATION
DROP LOCATION
ALTER LOCATION
EXOTIC FEATURES
---
These features are cool, but won't make it into the initial implementation
most likely:
1. The SET stuff above.
2. WAL location
3. Location quotas
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] plpgsql Integer Concat To String
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 values(IdForEachRun, ..) counter := counter + 1; IdForEachRun := IdSet || counter;(PROBLEM HERE) --Or IdForEachRun := IdSet + counter;(PROBLEM HERE) END LOOP END Language 'plpgsql' Thanks in advance. Paul Puneet ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Project status pages
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 these pages? Perhaps they should be moved into the
wiki framework up on techdocs?
Robert Treat
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:
>
> http://momjian.postgresql.org/main/writings/pgsql/project
>
> --
> Bruce Momjian| http://candle.pha.pa.us
> [EMAIL PROTECTED] | (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 5: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/docs/faqs/FAQ.html
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] TODO list
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 -0600 > From: Larry Rosenman <[EMAIL PROTECTED]> > To: Gavin Sherry <[EMAIL PROTECTED]>, > Bruce Momjian <[EMAIL PROTECTED]> > Cc: Marko Zmak <[EMAIL PROTECTED]>, [EMAIL PROTECTED], > Olivier PRENANT <[EMAIL PROTECTED]> > Subject: Re: [HACKERS] TODO list > > > > --On Thursday, December 18, 2003 08:07:03 +1100 Gavin Sherry > <[EMAIL PROTECTED]> wrote: > > > On Wed, 17 Dec 2003, Bruce Momjian wrote: > > > >> Marko Zmak wrote: > >> > > >> > I've been usin psql for quite a long time and I found it to be very > >> > comfortable. Since some web providers in my country refuse to put psql > >> > while some thing are still in psql TODO list, I'm interested in > >> > following... > >> > > >> > > >> > I'd like to know when are you planning to deal with this TODO item: > >> > > >> > Allow limits on per-db/user connections > >> > > >> > I would appreciate if it was as soon as possible. Thanks. > >> > >> I know of no one working on this feature. > > > > But I'm sure no one would have a problem with Marko attempting it :-). > I also know that Olivier PRENANT was looking for something similar. And > the same admonition goes. I.E., you have an itch, we'd love to see you > scratch it. > > LER > > > > > Gavin > > > > ---(end of broadcast)--- > > TIP 7: don't forget to increase your free space map settings > > > > > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Dates BC.
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)
> tm->tm_year = -(tm->tm_year - 1);
>
> It this normal or a bug?
Uh, well, yea, there was no year 0. However, it seems we should return
the proper year. My guess is that missing year 0 is the cause, and
there are certain reasons year 2 BC should return -1. If you are
subtracting dates, like 32AD - 4BC, you get 35, which is the proper
number of years spanned.
I am not sure what is the proper answer. I thought date_part just
grabbed "parts of the date" like it says, but obviously not, and there
are some good reasons for it, I guess.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (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 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [HACKERS] ecpg tests compile failure
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: 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? The ecpg/test/Makefile has: override CPPFLAGS := -I$(srcdir)/../include -I$(libpq_srcdir) $(CPPFLAGS) $(THREAD_CPPFLAGS) and %: %.o $(CC) $(CFLAGS) $(LDFLAGS) -L../ecpglib -L ../pgtypeslib -L../../libpq $^ $(LIBS) -lpgtypes -lecpg -lpq $(THREAD_LIBS) -o $@ so I see the thread compile and link flags mentioned in the Makefile. My guess is that you didn't compile the backend with --enable-thread-safety. I wonder if I should disable the thread ecpg test program when this compile option is not used. Is that correct? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 4: Don't 'kill -9' the postmaster
[HACKERS] Dates BC.
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 = -(tm->tm_year - 1);
It this normal or a bug?
Kurt
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] ecpg tests compile failure
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 PROTECTED] pgsql]$ grep THREAD_LIBS ./src/Makefile.global THREAD_LIBS = -lpthread If you don't have this flag defined, the tests won't be linked against the thread library. Check what value this flag is set to. You did a ./configure --enable-thread-safety, right? Which platform is this BTW? This is on a CVS head checkout from couple of days ago on linux.. All the tests got successfully compiled. Shridhar ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] ecpg tests compile failure
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 `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 > > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] ecpg tests compile failure
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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] ecpg tests compile failure
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 match
[HACKERS] apache rotate logs
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
