summaryrefslogtreecommitdiff
path: root/src/backend/utils/adt
Commit message (Collapse)AuthorAgeFilesLines
* From: "D'Arcy J.M. Cain" <darcy@druid.net>Marc G. Fournier1997-04-281-2/+2
| | | | | | | | | | Subject: [HACKERS] Inputting money I notice that I have to put single quotes around money amounts if there is a decimal point in the value. I appears to be happening because there is something changing things like "123.45" to "123.450000" and the code has a problem with that. There may be a better way to fix this but here is a simple change to cash.c that lets it accept trailing zeroes.
* Change mixed-case routines to lower-case if referenced in pg_proc.hThomas G. Lockhart1997-04-274-19/+179
| | | | | Add comparison operators to boolean and smaller/larger operators to datetime and timespan. Fix int4 overflow math problem in timespan comparison operators.
* Massive regression test patches from Thomas *woo hoo!*Marc G. Fournier1997-04-271-9/+24
|
* More timezone patches by Thomas:Marc G. Fournier1997-04-254-116/+248
| | | | | | | | | Here are patches which should help fix timezone problems in the datetime and abstime code. Also, I repatched varlena.c to add in some comments and a little error checking on top of Vadim's earlier repairs. There are slight mods to the circle data type to have the distance operator between circles measure the distance between closest points rather than between centers.
* From: "Pedro J. Lobo" <pjlobo@euitt.upm.es>Marc G. Fournier1997-04-241-3/+3
| | | | | | | | | | | | | | | | | Subject: [PATCHES] Patches for compiling 6.1 on Digital Unix 3.2c Attached to this message are the patches I needed to compile 6.1 cleanly under Digital Unix 3.2c with DEC cc. I hope these are the last ones. At least, the number of files needing a patch has decreased noticeably since I sent my previous patches. Nice work :-) One of the patches is a bug fix, but I'm including it here anyway. With these patches applied, the beast seems to work properly. However, I've done only some preliminary tests. More on this later (but hopefully before the April 30 deadline... :-)
* Add fcvt() as a check to configure so that we can get rid of the BSD44_derivedMarc G. Fournier1997-04-221-4/+2
| | | | | | type check in numutils.c:ftoa() Pointed out by: "Martin J. Laubach" <mjl@emsi.priv.at>
* From: Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>Marc G. Fournier1997-04-222-20/+69
| | | | | | | | | | | | | Subject: [PATCHES] date/time timezone patches (mail bounced?) Here are some hacks to get timezone behavior for the various time data types to be compatible with v6.0. Although we have some hooks already installed to get timezone info from the client to the server, it still isn't clear if that can correctly transfer enough timezone info to make the behavior the same as if timezone info were derived from the server as is now the case. We certainly won't resolve it in a day, so I think we are stuck with server-only timezones for v6.1.
* Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>Marc G. Fournier1997-04-221-544/+1815
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OK, here are a passel of patches for the geometric data types. These add a "circle" data type, new operators and functions for the existing data types, and change the default formats for some of the existing types to make them consistant with each other. Current formatting conventions (e.g. compatible with v6.0 to allow dump/reload) are supported, but the new conventions should be an improvement and we can eventually drop the old conventions entirely. For example, there are two kinds of paths (connected line segments), open and closed, and the old format was '(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4) '(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4) Pretty arcane, huh? The new format for paths is '((1,2),(3,4))' for a closed path with two points (1,2) and (3,4) '[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4) For polygons, the old convention is '(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3) and the new convention is '((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3) Other data types which are also represented as lists of points (e.g. boxes, line segments, and polygons) have similar representations (they surround each point with parens). For v6.1, any format which can be interpreted as the old style format is decoded as such; we can remove that backwards compatibility but ugly convention for v7.0. This will allow dump/reloads from v6.0. These include some updates to the regression test files to change the test for creating a data type from "circle" to "widget" to keep the test from trashing the new builtin circle type.
* Fix for text_lt/text_le to avoid warnings if not def USE_LOCALE.Vadim B. Mikheev1997-04-211-31/+31
|
* Here is the Mismatched input/output patch for tintervals as reported overMarc G. Fournier1997-04-201-4/+4
| | | | | | | the last week on Hackers...(A coulpe of clippings of the final verdict are included below + the diff). From: Wayde Nie <niew@phoenix.cis.mcmaster.ca>
* DeclarationVadim B. Mikheev1997-04-181-1/+3
| | | | | static const char *num_word(Cash value); moved here from cash.h
* From: "Martin J. Laubach" <mjl@CSlab.tuwien.ac.at>Marc G. Fournier1997-04-171-1/+2
| | | | | | | | | | | | | | | Subject: [HACKERS] Patch: set date to euro/us postgres/iso/sql Here a patch that implements a SET date for use by the datetime stuff. The syntax is SET date TO 'val[,val,...]' where val is us (us dates), euro (european dates), postgres, iso or sql. Thomas is working on the integration in his datetime module. I just needed to get the patch out before it went stale :)
* A small fix, where default: condition in case had not 'break;'...not required,Marc G. Fournier1997-04-151-1/+3
| | | | but, IMHO, cleaner
* From: Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>Marc G. Fournier1997-04-151-241/+488
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Subject: [HACKERS] Money integration patches Here are patches to integrate the money data type. I have included some math and aggregate functions and have made the locale support optional by #ifdef USE_LOCALE bracketing of functions. Modules affected are: builtins.h.patch cash.c.patch cash.h.patch main.c.patch pg_aggregate.h.patch pg_operator.h.patch pg_proc.h.patch pg_type.h.patch I changed the data type to be pass-by-reference rather than by-value to pave the way for a larger internal representation (64-bit ints?). Also, I changed the tabbing of cash.c and cash.h to match most of the other Postgres source code files (4 space indent, 8 spaces == 1 tab). The locale stuff should be tested under another convention (Russian?) but I don't know what the correct results should be so perhaps someone else can give them a try. Will update docs and regression tests in the next few days.
* Add ccsym to tools to determine OS/compiler specific symbolsMarc G. Fournier1997-04-131-2/+2
| | | | | Change BSD44_derived to __FreeBSD__ in numutils.c (need to know what NetBSD is referred to as...someone?)
* Finish removing the TEST_MAIN stuff, which was mean for standaloneMarc G. Fournier1997-04-101-29/+1
| | | | testing
* Fix #include "cash.h" to be #include <utils/cash.h>Marc G. Fournier1997-04-101-8/+1
| | | | Remove the TEST_MAIN stuff at the top...
* Add in D'Arcy's cash codeMarc G. Fournier1997-04-092-2/+311
| | | | | | pg_proc.h still needs modifying, but this gets it in there so that we can get around any compiler bugs. Will try and get the pg_proc.h entries done up later tonight...
* GNUmakefile.in - remove backend/utils/Gen_fmgrtab.sh on distcleanMarc G. Fournier1997-04-091-39/+82
| | | | varlena.c - part of Thomas' most recent patch
* getattnvals(): if attnvals in pg_attribute is 0 then useVadim B. Mikheev1997-04-091-1/+10
| | | | ATTNVALS_SCALE/reltuples (instead of reltuples).
* From: Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>Marc G. Fournier1997-04-051-2/+2
| | | | | | | | Subject: [HACKERS] Fix for European dates This apparently fixes the European date reading problem reported by several (European) bleeding edge adopters. I tried a few test cases and it doesn't break the non-EuroDate cases in my test suite.
* Again, needs float.hMarc G. Fournier1997-04-041-1/+4
|
* needs float.h for DBL_MIN under FreeBSDMarc G. Fournier1997-04-041-1/+4
|
* From: "D'Arcy J.M. Cain" <darcy@druid.net>Marc G. Fournier1997-04-031-9/+89
| | | | | | | | | | | Subject: [HACKERS] timestamp.c changes I sent in changes previously and they were rejected because they didn't follow ANSI spec. Here is the input part of the changes again. Even though it allows more flexibility for inputting different formats, it is also backwards compatible with the standard version. I have also not changed the output format so it will still output the ANSI forms. Is this acceptable to everyone?
* From: Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>Marc G. Fournier1997-04-025-239/+669
| | | | | | | | | | | | | | | | | | | | | | | | | Subject: [HACKERS] More date time functions Here are some additional patches mostly related to the date and time data types. It includes some type conversion routines to move between the different date types and some other date manipulation routines such as date_part(units,datetime). I noticed Edmund Mergl et al's neat trick for getting function overloading for builtin functions, so started to use that for the date and time stuff. Later, if someone figures out how to get function overloading directly for internal C code, then we can move to that technique. These patches include documentation updates (don't faint!) for the built-in man page. Doesn't yet include mention of timestamp, since I don't know much about it and since it may change a bit to become a _real_ ANSI timestamp which would include parser support for the declaration syntax (what do you think, Dan?). The patches were developed on the 970330 release, but have been rebuilt off of the 970402 release. The first patch below is to get libpq to compile, on my Linux box, but is not related to the rest of the patches and you can choose not to apply that one at this time. Thanks in advance, scrappy!
* From: Oleg Bartunov <oleg@sai.msu.su>Marc G. Fournier1997-04-021-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | Subject: [HACKERS] locale patches ! Hi there, here are little patches to get Postgres 6.1 works with locale stuff. This is a patch against 970402.tar.gz, there are no problem to apply them by hand to 6.0 release. Collate stuff tested about 1-2 months in real working database but I'm sure there must be no problem. US hackers could vote against locale implementation ( locale for sure will affect to speed of postgres ), so I introduce variable USE_LOCALE which controls locale stuff. Non-US users now could use ~* operator for searching and <order by> for strings with nation alphabet. Please, don't forget, as I did first time, to set environment variable LC_CTYPE and LC_COLLATE because backend get locale information from them. I start postmaster from a little script, assuming that shell is Bash shell it looks like: #!/bin/sh export LC_CTYPE=koi8-r export LC_COLLATE=koi8-r postmaster -B 1024 -S -D/usr/local/pgsql/data/ -o '-Fe'
* From: Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>Marc G. Fournier1997-03-281-1/+4
| | | | | | | | | | | | | Subject: [HACKERS] Small date patches (resubmitted) Here a some small patches for the date/time code. They set the default output format for the datetime type to the traditional Postgres style, and fix a date debugging declaration. I submitted these a couple of days ago, but they might have gotten lost... NOTE: the second patch to dt.c is what I believe D'Arcy submitted as well, that I claimed was taken out...sorry D'Arcy, my fault :(
* From: Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>Marc G. Fournier1997-03-282-136/+68
| | | | | | | | | | | | | | | | | | | Subject: Re: [HACKERS] abstime "now" broken Yes, I broke 'now' :( with an attempt at a bug fix involving servers running in the UTC/GMT timezone. These patches fix the problem, and have been tested in GMT (+00 hours), PST (-08), and NZT (+12) timezones which exercized the code for various cases including across day boundaries. btw, this code fixes the same type of problem for 'today', 'yesterday', 'tomorrow', for DATETIME, ABSTIME, DATE and TIME types. The bugfix itself is quite small, but I have accumulated other changes in the datetime data type and include them here also. One set of changes involves printing ISO-formatted dates and is in response to the helpful information from Kurt Lidl regarding ANSI SQL dates. I'll send another e-mail sometime soon discussing more issues he has raised...
* From: "D'Arcy J.M. Cain" <darcy@druid.net>Marc G. Fournier1997-03-281-1/+4
| | | | Some systems require limits.h to define DBL_MIN.
* On some systems limits.h is needed to define DBL_MIN.Marc G. Fournier1997-03-281-1/+4
| | | | From: "D'Arcy J.M. Cain" <darcy@druid.net>
* include float.h *after* postgres.h :(Marc G. Fournier1997-03-261-4/+4
|
* need float.h under FreeBSD for DBL_MINMarc G. Fournier1997-03-261-1/+4
|
* Add checs for float.hMarc G. Fournier1997-03-251-2/+1
| | | | Remove 'unused variable' from dt.c
* Add float.h for DBL_{MIN,MAX} under FreeBSDMarc G. Fournier1997-03-251-1/+4
|
* From: "D'Arcy J.M. Cain" <darcy@druid.net>Marc G. Fournier1997-03-251-32/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Subject: [HACKERS] backend/utils/adt/timestamp.c Back to this timezone stuff. The struct tm has a field (tm_gmtoff) which is the offset from UTC (GMT is archaic BTW) in seconds. Is this the value you are looking for when you use timezone? Note that this applies to NetBSD but it does not appear to be in either ANSI C or POSIX. This looks like one of those things that is just going to have to be hand coded for each platform. Why not just store the values in UTC and use localtime instead of gmtime when retrieving the value? Also, you assume the time is returned as a 4 byte integer. In fact, there is not even any requirement that time be an integral value. You should use time_t here. The input function seems unduly restrictive. Somewhere in the sources there is an input function that allows words for months. Can't we do the same here? There is a standard function, difftime, for subtracting two times. It deals with cases where time_t is not integral. There is, however, a small performance hit since it returns a double and I don't believe there is any system currently which uses anything but an integral for time_t. Still, this is technically the correct and portable thing to do. The returns from the various comparisons should probably be a bool.
* From: Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>Marc G. Fournier1997-03-252-459/+1032
| | | | | | | | | | | | | | | | | | | | | Subject: [HACKERS] More patches for date/time I have accumulated several patches to add functionality to the datetime and timespan data types as well as to fix reported porting bugs on non-BSD machines. These patches are: dt.c.patch - add datetime_part(), fix bugs dt.h.patch - add quarter and timezone support, add prototypes globals.c.patch - add time and timezone variables miscadmin.h.patch - add time and timezone variables nabstime.c.patch - add datetime conversion routine nabstime.h.patch - add prototypes pg_operator.h.patch - add datetime operators, clean up formatting pg_proc.h.patch - add datetime functions, reassign conflicting date OIDs pg_type.h.patch - add datetime and timespan data types The dt.c and pg_proc.h patches are fairly large; the latter mostly because I tried to get some columns for existing entries to line up.
* From: "D'Arcy J.M. Cain" <darcy@druid.net>Marc G. Fournier1997-03-211-3/+3
| | | | | | | | | | Subject: [HACKERS] backend/utils/adt/nabstime.c There is a problem with some of the calls to strftime. The second arg is missing. In all cases the buffer is CTZName which, according to the file init/globals.c, is char CTZName[8] so I have added this value. I know there should be a #define set up for this but I wasn't sure which header to put it in.
* Resync the source tree, commit some things that were missing (pqcomprim.c) andMarc G. Fournier1997-03-182-62/+49
| | | | bring in Thomas's updates for the date/time code...
* oracle_compat.c fixed for function overloading...Marc G. Fournier1997-03-161-286/+48
| | | | By: From: Edmund Mergl <mergl@nadia.s.bawue.de>
* From: Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>Marc G. Fournier1997-03-161-4/+4
| | | | | | | | | | | Subject: [HACKERS] Patches for 970316 compilation I made a small pre-emptive change in the new datetime code to eliminate calls to infnan(). Hopefully this will make Solaris (and probably other non-GNUlib) systems happier. Didn't find fe-connect.h in the 970316 distribution, so made one up. Also, one of the test routines needs an update for the geo-decls.h -> geo_decls.h name change. Patches appear below...
* Header file fixes for MINDOUBLEMarc G. Fournier1997-03-161-3/+7
|
* Add a conditional for <values.h> vs <limits.h>Marc G. Fournier1997-03-161-1/+6
|
* Remove extra functions temporarily while a proper fix is found...Marc G. Fournier1997-03-161-1/+3
|
* Update oracle_compat.cMarc G. Fournier1997-03-151-84/+365
|
* Date/Time updates from Thomas...Marc G. Fournier1997-03-1415-1410/+3359
|
* Missed another tar file... :(Marc G. Fournier1997-03-141-0/+98
|
* From: Dan McGuirk <mcguirk@indirect.com>Marc G. Fournier1997-03-121-4/+3
| | | | | | Subject: [HACKERS] timestamp type OK, last one. This patch adds an ANSI SQL 'timestamp' type.
* From: Dan McGuirk <mcguirk@indirect.com>Marc G. Fournier1997-03-122-10/+30
| | | | | | | | | | Subject: [HACKERS] linux/alpha patches These patches lay the groundwork for a Linux/Alpha port. The port doesn't actually work unless you tweak the linker to put all the pointers in the first 32 bits of the address space, but it's at least a start. It implements the test-and-set instruction in Alpha assembly, and also fixes a lot of pointer-to-integer conversions, which is probably good anyway.
* Add prototypes for oracle-compat functions. Rename geo-*.c adt to geo_*.cBruce Momjian1997-03-094-5/+6
|
* This is a set of single row character functions, defined for the datatypeMarc G. Fournier1997-03-042-2/+423
| | | | | | text, which are supposed to behave exactly as their Oracle counterparts. From: Edmund Mergl <E.Mergl@bawue.de>