diff --git a/INSTALL b/INSTALL index 5a86468edf..ad0a2d4d91 100644 --- a/INSTALL +++ b/INSTALL @@ -1,9 +1,3 @@ -Chapter 0. Installation - -Table of Contents -Before you start -Installation Procedure - Installation instructions for PostgreSQL 7.0. Commands were tested on RedHat Linux version 5.2 using the bash shell. @@ -58,7 +52,6 @@ Considering today's prices for hard disks, getting a large and fast hard disk should probably be in your plans before putting a database into production use. ---------------------------------------------------------------------------- Installation Procedure @@ -79,7 +72,7 @@ For a fresh install or upgrading from previous releases of PostgreSQL: (although you can). You will be told when you need to login as the database superuser. - 2. If you are not upgrading an existing system then skip to . + 2. If you are not upgrading an existing system then skip to step 4. You now need to back up your existing database. To dump your fairly recent post-6.0 database installation, type @@ -103,6 +96,7 @@ For a fresh install or upgrading from previous releases of PostgreSQL: backup. If necessary, bring down postmaster, edit the permissions in file /usr/local/pgsql/data/pg_hba.conf to allow only you on, then bring postmaster back up. + 3. If you are upgrading an existing system then kill the database server now. Type @@ -140,11 +134,13 @@ For a fresh install or upgrading from previous releases of PostgreSQL: make choices about what gets installed. Change into the src subdirectory and type: - $ ./configure [ options ] + $ ./configure - For a complete list of options, type: + followed by any options you might want to give it. For a first + installation you should be able to do fine without any. For a complete + list of options, type: - ./configure --help + ./configure --help Some of the more commonly used ones are: @@ -231,12 +227,15 @@ For a fresh install or upgrading from previous releases of PostgreSQL: The -D option specifies the location where the data will be stored. You can use any path you want, it does not have to be under the installation directory. Just make sure that the superuser account can - write to it (or create it) before starting initdb. + write to the directory (or create it) before starting initdb. (If you + have already been doing the installation up to now as the PostgreSQL + superuser, you may have to log in as root temporarily to create the + data directory.) 9. The previous step should have told you how to start up the database server. Do so now. - $ /usr/local/pgsql/initdb/postmaster -D /usr/local/pgsql/data + $ /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data This will start the server in the foreground. To make it detach to the background, use the -S. @@ -270,7 +269,12 @@ suggestions. $ cd /usr/src/pgsql/postgresql-7.0/doc $ gmake install - This will install files under /usr/local/pgsql/doc. + This will install files under /usr/local/pgsql/doc and + /usr/local/pgsql/man. To enable your system to find the man + documentation, you need to add a line like the following to a shell + startup file: + + MANPATH=$MANPATH:/usr/local/pgsql/man The documentation is also available in Postscript format. If you have a Postscript printer, or have your machine already set up to accept diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml index 44dfabaa28..9bb40e73f2 100644 --- a/doc/src/sgml/datatype.sgml +++ b/doc/src/sgml/datatype.sgml @@ -541,509 +541,106 @@ CREATE TABLE tablename (Date/Time Types - There are two fundamental kinds of date and time measurements - provided by Postgres: - absolute clock times and relative time intervals. - Both kinds of time measurements should demonstrate both - continuity and smoothness. - - - - Postgres supplies two primary user-oriented - date and time types, - datetime and timespan, as well as - the related SQL92 types timestamp, - interval, - date and time. - - - - In a future release, datetime and timespan are likely - to merge with the SQL92 types timestamp, - interval. - Other date and time types are also available, mostly - for historical reasons. + PostgreSQL supports the full set of + SQL date and time types. - <productname>Postgres</productname> Date/Time Types + <productname>PostgreSQL</productname> Date/Time TypesDate/Time - Date/Time Type + Type + Description Storage - Recommendation - Description + Earliest + Latest + Resolution - abstime - 4 bytes - original date and time - limited range + timestamp + for data containing both date and time + 8 bytes + 4713 BC + AD 1465001 + 1 microsec / 14 digits - date - 4 bytes - SQL92 type - wide range + interval + for time intervals + 12 bytes + -178000000 years + 178000000 years + 1 mircosecond - datetime - 8 bytes - best general date and time - wide range, high precision + date + for data containing only dates + 4 bytes + 4713 BC + 32767 AD + 1 day - interval - 12 bytes - SQL92 type - equivalent to timespan - - - reltime - 4 bytes - original time interval - limited range, low precision - - - time - 4 bytes - SQL92 type - wide range - - - timespan - 12 bytes - best general time interval - wide range, high precision - - - timestamp - 4 bytes - SQL92 type - limited range + time + for data containing only times of the day + 4 bytes + 00:00:00.00 + 23:59:59.99 + 1 microsecond
- timestamp is currently implemented separately from - datetime, although they share input and output routines. + + + To ensure compatibility to earlier versions of PostgreSQL + we also continue to provide datetime (equivalent to timestamp) and + timespan (equivalent to interval). The types abstime + and reltime are lower precision types which are used internally. + You are discouraged from using any of these types in new applications and move any old + ones over when appropriate. Any or all of these type might disappear in a future release. + + - - - <productname>Postgres</productname> Date/Time Ranges - Ranges - - - - Date/Time Type - Earliest - Latest - Resolution - - - - - abstime - 1901-12-14 - 2038-01-19 - 1 sec - - - date - 4713 BC - 32767 AD - 1 day - - - datetime - 4713 BC - 1465001 AD - 1 microsec to 14 digits - - - interval - -178000000 years - 178000000 years - 1 microsec - - - reltime - -68 years - +68 years - 1 sec - - - time - 00:00:00.00 - 23:59:59.99 - 1 microsec - - - timespan - -178000000 years - 178000000 years - 1 microsec (14 digits) - - - timestamp - 1901-12-14 - 2038-01-19 - 1 sec - - - -
- - - - SQL92 Conventions - - - Postgres endeavors to be compatible with - SQL92 definitions for typical usage. - However, the SQL92 standard has an odd mix of date and - time types and capabilities. Two obvious problems are: - - - - - Although the date type - does not have an associated time zone, the - time type can or does. - - - - - - The default time zone is specified as a constant integer offset - from GMT/UTC. - - - - - - Time zones in the real world can have no meaning unless - associated with a date as well as a time - since the offset may vary through the year with daylight savings - time boundaries. - - - - To address these difficulties, Postgres - associates time zones only with date and time - types which contain both date and time, - and assumes local time for any type containing only - date or time. Further, time zone support is derived from - the underlying operating system - time zone capabilities, and hence can handle daylight savings time - and other expected behavior. - - - - In future releases, the number of date/time types will decrease, - with the current implementation of - datetime becoming timestamp, - timespan becoming interval, - and (possibly) abstime and reltime - being deprecated in favor of timestamp and interval. - The more arcane features of the date/time definitions from - the SQL92 standard are not likely to be pursued. - - - - - Date/Time Styles - - - Output formats can be set to one of four styles: - ISO-8601, SQL (Ingres), traditional - Postgres, and German. - - - <productname>Postgres</productname> Date Styles - Styles - - - - Style Specification - Description - Example - - - - - ISO - ISO-8601 standard - 1997-12-17 07:37:16-08 - - - SQL - Traditional style - 12/17/1997 07:37:16.00 PST - - - Postgres - Original style - Wed Dec 17 07:37:16 1997 PST - - - German - Regional style - 17.12.1997 07:37:16.00 PST - - - -
- - - - The SQL style has European and non-European (US) variants, - which determines whether month follows day or vica versa. - - - <productname>Postgres</productname> Date Order Conventions - Order - - - - Style Specification - Description - Example - - - - - European - Regional convention - 17/12/1997 15:37:16.00 MET - - - NonEuropean - Regional convention - 12/17/1997 07:37:16.00 PST - - - US - Regional convention - 12/17/1997 07:37:16.00 PST - - - -
- - - - There are several ways to affect the appearance of date/time types: - - - - - The PGDATESTYLE environment variable used by the backend directly - on postmaster startup. - - - - - The PGDATESTYLE environment variable used by the frontend libpq - on session startup. - - - - - SET DATESTYLE SQL command. - - - - - - - For Postgres v6.5 (and earlier) - the default date/time style is - "non-European traditional Postgres". - In future releases, the default may become "ISO" (compatible with ISO-8601), - which alleviates date specification ambiguities and Y2K collation problems. - - - - - - Calendar - - - Postgres uses Julian dates - for all date/time calculations. They have the nice property of correctly - predicting/calculating any date more recent than 4713BC - to far into the future, using the assumption that the length of the - year is 365.2425 days. - - - - Date conventions before the 19th century make for interesting reading, - but are not consistant enough to warrant coding into a date/time handler. - - - - - Time Zones - - - Postgres obtains time zone support - from the underlying operating system for dates between 1902 and - 2038 (near the typical date limits for Unix-style - systems). Outside of this range, all dates are assumed to be - specified and used in Universal Coordinated Time (UTC). - - - - All dates and times are stored internally in Universal UTC, - alternately known as Greenwich Mean Time (GMT). - Times are converted to local time on the database server before being - sent to the client frontend, hence by default are in the server - time zone. - - - - There are several ways to affect the time zone behavior: - - - - - The TZ environment variable used by the backend directly - on postmaster startup as the default time zone. - - - - - The PGTZ environment variable set at the client used by libpq - to send time zone information to the backend upon connection. - - - - - The SQL command SET TIME ZONE - sets the time zone for the session. - - - - - - - If an invalid time zone is specified, - the time zone becomes GMT (on most systems anyway). - - Date/Time Input - General-use date and time is input using a wide range of - styles, including ISO-compatible, SQL-compatible, - traditional Postgres - and other permutations of date and time. In cases where interpretation - can be ambiguous (quite possible with many traditional styles of date - specification) Postgres uses a style setting - to resolve the ambiguity. + Date and time input is accepted in almost any reasonable format, including + ISO-compatible, SQL-compatible, + traditional Postgres, and others. + The ordering of month and day in date input can be ambiguous, therefore a setting + exists, to specify how it should be interpreted. The command + SET DateStyle TO 'US' or SET DateStyle TO 'NonEuropean' + specifies the variant month before day, the command + SET DateStyle TO 'European' sets the variant + day before month. The former is the default. - Most date and time types share code for data input. For those types - the input can have any of a wide variety of styles. For numeric date - representations, - European and US conventions can differ, and the proper interpretation - is obtained by using the SET DATESTYLE - command before entering data. - Note that the style setting does not preclude use of various styles for input; - it is used primarily to determine the output style and to resolve ambiguities. + See + for the exact parsing rules of date/time input and for the recognized time zones. - The special values current, - infinity and -infinity are provided. - infinity specifies a time later than any other valid time, and - -infinity specifies a time earlier than any other valid time. - current indicates that the current time should be - substituted whenever this value appears in a computation. - - - - The strings - now, - today, - yesterday, - tomorrow, - and epoch - can be used to specify time values. - now - means the current transaction time, and differs from - current - in that the current time is immediately substituted for it. - epoch means Jan 1 00:00:00 1970 GMT. + Remember that any date or time input needs to be enclosed into single quotes, + like text strings. + + date + The following are possible inputs for the date type. - <productname>Postgres</productname> Date/Time Special Constants - Constants - - - - Constant - Description - - - - - current - Current transaction time, deferred - - - epoch - 1970-01-01 00:00:00+00 (Unix system time zero) - - - infinity - Later than other valid times - - - -infinity - Earlier than other valid times - - - invalid - Illegal entry - - - now - Current transaction time - - - today - Midnight today - - - tomorrow - Midnight tomorrow - - - yesterday - Midnight yesterday - - - -
- - - - - <productname>Postgres</productname> Date Input + <productname>PostgreSQL</productname> Date InputDate Inputs @@ -1055,11 +652,11 @@ CREATE TABLE tablename ( January 8, 1999 - Unambiguous text month + Unambiguous 1999-01-08 - ISO-8601 + ISO-8601 format, preferred 1/8/1999 @@ -1095,7 +692,7 @@ CREATE TABLE tablename ( January 8, 99 BC - Year 99 before the Christian Era + Year 99 before the common era @@ -1104,7 +701,7 @@ CREATE TABLE tablename (
- <productname>Postgres</productname> Month Abbreviations + <productname>PostgreSQL</productname> Month AbbreviationsMonth Abbreviations @@ -1171,7 +768,7 @@ CREATE TABLE tablename (
- <productname>Postgres</productname> Day of Week Abbreviations + <productname>PostgreSQL</productname> Day of Week AbbreviationsDay of Week Abbreviations @@ -1213,10 +810,14 @@ CREATE TABLE tablename (
+ + + time + The following are valid time inputs. - <productname>Postgres</productname> Time Input + <productname>PostgreSQL</productname> Time InputTime Inputs @@ -1228,7 +829,7 @@ CREATE TABLE tablename ( 04:05:06.789 - ISO-8601, with all time fields + ISO-8601 04:05:06 @@ -1266,10 +867,29 @@ CREATE TABLE tablename (
+ + + + timestamp + + Valid input for the timestamp type consists of a concatenation + of a date and a time, followed by an optional AD or + BC, followed by an optional time zone. (See below.) + Thus + +1999-01-08 04:05:06 -8:00 + + is a valid timestamp value, which is ISO-compliant. + In addition, the wide-spread format + +January 8 04:05:06 1999 PST + + is supported. + - <productname>Postgres</productname> Time Zone Input + <productname>PostgreSQL</productname> Time Zone InputTime Zone Inputs @@ -1299,10 +919,305 @@ CREATE TABLE tablename (
+ + + + interval + + intervals can be specified with the following syntax: + + Quantity Unit [Quantity Unit...] [Direction] +@ Quantity Unit [Direction] + + where: Quantity is ..., -1, + 0, 1, 2, ...; + Unit is second, + minute, hour, day, + week, month, year, + decade, century, millenium, + or abbreviations or plurals of these units; + Direction can be ago or + empty. + + + + + Special values + + The following SQL-compatible functions can be used as date or time + input for the corresponding datatype: CURRENT_DATE, + CURRENT_TIME, CURRENT_TIMESTAMP. + + + PostgreSQL also supports several special constants for + convenience. + + + <productname>PostgresSQL</productname> Special Date/Time Constants + Constants + + + + Constant + Description + + + + + current + Current transaction time, deferred + + + epoch + 1970-01-01 00:00:00+00 (Unix system time zero) + + + infinity + Later than other valid times + + + -infinity + Earlier than other valid times + + + invalid + Illegal entry + + + now + Current transaction time + + + today + Midnight today + + + tomorrow + Midnight tomorrow + + + yesterday + Midnight yesterday + + + +
+ 'now' is resolved when the value is inserted, 'current' + is resolved everytime the value is retrieved. So you probably want to use 'now' + in most applications. (Of course you really want to use + CURRENT_TIMESTAMP, which is equivalent to 'now'.) + + + + + + + + Date/Time Output + + + Output formats can be set to one of the four styles + ISO-8601, SQL (Ingres), traditional + Postgres, and German, using the SET DateStyle. + The default is the ISO format. + + + <productname>PostgreSQL</productname> Date/Time Output Styles + Styles + + + + Style Specification + Description + Example + + + + + 'ISO' + ISO-8601 standard + 1997-12-17 07:37:16-08 + + + 'SQL' + Traditional style + 12/17/1997 07:37:16.00 PST + + + 'Postgres' + Original style + Wed Dec 17 07:37:16 1997 PST + + + 'German' + Regional style + 17.12.1997 07:37:16.00 PST + + + +
+ + + + The output of the date and time styles is of course + only the date or time part in accordance with the above examples + + + + The SQL style has European and non-European (US) variants, + which determines whether month follows day or vica versa. (See also above + at Date/Time Input, how this setting affects interpretation of input values.) + + + <productname>PostgreSQL</productname> Date Order Conventions + Order + + + + Style Specification + Example + + + + + European + 17/12/1997 15:37:16.00 MET + + + US + 12/17/1997 07:37:16.00 PST + + + +
+ + + + interval output looks like the input format, expect that units like + week or century are converted to years and days. + In ISO mode the output looks like + +[ Quantity Units [ ... ] ] [ Days ] Hours:Minutes [ ago ] + + + + + There are several ways to affect the appearance of date/time types: + + + + + The PGDATESTYLE environment variable used by the backend directly + on postmaster startup. + + + + + The PGDATESTYLE environment variable used by the frontend libpq + on session startup. + + + + + SET DATESTYLE SQL command. + + + + + + + + + Time Zones + + + PostgreSQL endeavors to be compatible with + SQL92 definitions for typical usage. + However, the SQL92 standard has an odd mix of date and + time types and capabilities. Two obvious problems are: + + + + + Although the date type + does not have an associated time zone, the + time type can or does. + + + + + + The default time zone is specified as a constant integer offset + from GMT/UTC. + + + + + + Time zones in the real world can have no meaning unless + associated with a date as well as a time + since the offset may vary through the year with daylight savings + time boundaries. + + + + To address these difficulties, PostgreSQL + associates time zones only with date and time + types which contain both date and time, + and assumes local time for any type containing only + date or time. Further, time zone support is derived from + the underlying operating system + time zone capabilities, and hence can handle daylight savings time + and other expected behavior. + + + + PostgreSQL obtains time zone support + from the underlying operating system for dates between 1902 and + 2038 (near the typical date limits for Unix-style + systems). Outside of this range, all dates are assumed to be + specified and used in Universal Coordinated Time (UTC). + + + + All dates and times are stored internally in Universal UTC, + alternately known as Greenwich Mean Time (GMT). + Times are converted to local time on the database server before being + sent to the client frontend, hence by default are in the server + time zone. + + + + There are several ways to affect the time zone behavior: + + + + + The TZ environment variable used by the backend directly + on postmaster startup as the default time zone. + + + + + The PGTZ environment variable set at the client used by libpq + to send time zone information to the backend upon connection. + + + + + The SQL command SET TIME ZONE + sets the time zone for the session. + + + + + + + If an invalid time zone is specified, + the time zone becomes GMT (on most systems anyway). + - See - for details on time zones recognized by Postgres. @@ -1313,201 +1228,22 @@ CREATE TABLE tablename ( - - Australian time zones and their naming variants - account for fully one quarter of all time zones in the - Postgres time zone lookup table. - - - <type>datetime</type> + Internals - General-use date and time is input using a wide range of - styles, including ISO-compatible, SQL-compatible, traditional - Postgres (see section on "absolute time") - and other permutations of date and time. Output styles can be ISO-compatible, - SQL-compatible, or traditional - Postgres, with the default set to be compatible - with Postgres v6.0. + PostgreSQL uses Julian dates + for all date/time calculations. They have the nice property of correctly + predicting/calculating any date more recent than 4713BC + to far into the future, using the assumption that the length of the + year is 365.2425 days. - datetime is specified using the following syntax: - - -Year-Month-Day [ Hour : Minute : Second ] [AD,BC] [ Timezone ] - YearMonthDay [ Hour : Minute : Second ] [AD,BC] [ Timezone ] - Month Day [ Hour : Minute : Second ] Year [AD,BC] [ Timezone ] -where - Year is 4013 BC, ..., very large - Month is Jan, Feb, ..., Dec or 1, 2, ..., 12 - Day is 1, 2, ..., 31 - Hour is 00, 02, ..., 23 - Minute is 00, 01, ..., 59 - Second is 00, 01, ..., 59 (60 for leap second) - Timezone is 3 characters or ISO offset to GMT - - - - - Valid dates are from Nov 13 00:00:00 4013 BC GMT to far into the future. - Timezones are either three characters (e.g. "GMT" or "PST") or ISO-compatible - offsets to GMT (e.g. "-08" or "-08:00" when in Pacific Standard Time). - Dates are stored internally in Greenwich Mean Time. Input and output routines - translate time to the local time zone of the server. - - - - - <type>timespan</type> - - - General-use time span is input using a wide range of - syntaxes, including ISO-compatible, SQL-compatible, - traditional - Postgres (see section on "relative time") - and other permutations of time span. Output formats can be ISO-compatible, - SQL-compatible, or traditional - Postgres, - with the default set to be Postgres-compatible. - Months and years are a "qualitative" time interval, and are stored separately - from the other "quantitative" time intervals such as day or hour. - For date arithmetic, - the qualitative time units are instantiated in the context of the - relevant date or time. - - - - Time span is specified with the following syntax: - - - Quantity Unit [Quantity Unit...] [Direction] -@ Quantity Unit [Direction] -where - Quantity is ..., -1, 0, 1, 2, ... - Unit is second, minute, hour, day, week, month, year, - decade, century, millenium, or abbreviations or plurals of these units. - Direction is ago. - - - - - - <type>abstime</type> - - - Absolute time (abstime) is a limited-range (+/- 68 years) and - limited-precision (1 sec) - date data type. datetime may be preferred, since it - covers a larger range with greater precision. - - - - Absolute time is specified using the following syntax: - - -Month Day [ Hour : Minute : Second ] Year [ Timezone ] -where - Month is Jan, Feb, ..., Dec - Day is 1, 2, ..., 31 - Hour is 01, 02, ..., 24 - Minute is 00, 01, ..., 59 - Second is 00, 01, ..., 59 - Year is 1901, 1902, ..., 2038 - - - - - Valid dates are from Dec 13 20:45:53 1901 GMT - to Jan 19 03:14:04 2038 GMT. - - - Historical Note - - As of Version 3.0, times are no longer read and written - using Greenwich Mean Time; the input and output routines default to - the local time zone. - - - All special values allowed for datetime are also - allowed for "absolute time". - - - - - - <type>reltime</type> - - - Relative time reltime is a limited-range (+/- 68 years) - and limited-precision (1 sec) time span data type. - timespan should be preferred, since it - covers a larger range with greater precision and, more importantly, - can distinguish between - relative units (months and years) and quantitative units (days, hours, etc). - Instead, reltime - must force months to be exactly 30 days, so time arithmetic does not - always work as expected. - For example, adding one reltime year to - abstime today does not - produce today's date one year from - now, but rather a date 360 days from today. - - - - reltime shares input and output routines with the other - time span types. - The section on timespan covers this in more detail. - - - - - - <type>timestamp</type> - - - This is currently a limited-range absolute time which closely resembles the - abstime - data type. It shares the general input parser with the other date/time types. - In future releases this type will absorb the capabilities of the - datetime type - and will move toward SQL92 compliance. - - - - timestamp is specified using the same syntax as for - datetime. - - - - - <type>interval</type> - - - interval is an SQL92 data type which is - currently mapped to the timespan - Postgres data type. - - - - - <type>tinterval</type> - - - Time ranges are specified as: - - -[ 'abstime' 'abstime'] -where - abstime is a time in the absolute time format. - - - Special abstime values such as - current, infinity and - -infinity can be used. + Date conventions before the 19th century make for interesting reading, + but are not consistant enough to warrant coding into a date/time handler. diff --git a/doc/src/sgml/install.sgml b/doc/src/sgml/install.sgml index b7a72da96d..50ea48ba8a 100644 --- a/doc/src/sgml/install.sgml +++ b/doc/src/sgml/install.sgml @@ -209,11 +209,13 @@ you can specify your actual installation path for the build process and make choices about what gets installed. Change into the src subdirectory and type: -$ ./configure [ options ] +$ ./configure +followed by any options you might want to give it. For a first installation +you should be able to do fine without any. For a complete list of options, type: - ./configure --help +./configure --help Some of the more commonly used ones are: @@ -359,7 +361,9 @@ $ /usr/local/pgsql/initdb -D /usr/local/pgsql/data The option specifies the location where the data will be stored. You can use any path you want, it does not have to be under the installation directory. Just make sure that the superuser account -can write to it (or create it) before starting initdb. +can write to the directory (or create it) before starting initdb. +(If you have already been doing the installation up to now as the PostgreSQL +superuser, you may have to log in as root temporarily to create the data directory.) @@ -368,7 +372,7 @@ can write to it (or create it) before starting initdb. The previous step should have told you how to start up the database server. Do so now. -$ /usr/local/pgsql/initdb/postmaster -D /usr/local/pgsql/data +$ /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data This will start the server in the foreground. To make it detach to the background, use the . @@ -420,7 +424,13 @@ You probably want to install the man and $ cd /usr/src/pgsql/postgresql-7.0/doc $ gmake install -This will install files under /usr/local/pgsql/doc. +This will install files under /usr/local/pgsql/doc +and /usr/local/pgsql/man. To enable your system +to find the man documentation, you need to +add a line like the following to a shell startup file: + +MANPATH=$MANPATH:/usr/local/pgsql/man + diff --git a/src/backend/parser/scan.l b/src/backend/parser/scan.l index 83afeb7a41..090f5911db 100644 --- a/src/backend/parser/scan.l +++ b/src/backend/parser/scan.l @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $Header: /cvsroot/pgsql/src/backend/parser/scan.l,v 1.61 2000/01/20 05:26:53 tgl Exp $ + * $Header: /cvsroot/pgsql/src/backend/parser/scan.l,v 1.62 2000/01/23 01:27:35 petere Exp $ * *------------------------------------------------------------------------- */ @@ -338,8 +338,11 @@ other . isupper(yytext[i])) yytext[i] = tolower(yytext[i]); if (i >= NAMEDATALEN) + { + elog(NOTICE, "identifier \"%s\" will be truncated to \"%.*s\"", + yytext, NAMEDATALEN-1, yytext); yytext[NAMEDATALEN-1] = '\0'; - + } keyword = ScanKeywordLookup((char*)yytext); if (keyword != NULL) { return keyword->value; diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c index 333da8cbc9..a12d311b2e 100644 --- a/src/bin/psql/command.c +++ b/src/bin/psql/command.c @@ -3,7 +3,7 @@ * * Copyright 2000 by PostgreSQL Global Development Team * - * $Header: /cvsroot/pgsql/src/bin/psql/command.c,v 1.14 2000/01/22 14:20:51 petere Exp $ + * $Header: /cvsroot/pgsql/src/bin/psql/command.c,v 1.15 2000/01/23 01:27:37 petere Exp $ */ #include #include "command.h" @@ -1198,6 +1198,7 @@ process_file(char *filename) { FILE *fd; int result; + char *oldfilename; if (!filename) return false; @@ -1214,10 +1215,11 @@ process_file(char *filename) return false; } + oldfilename = pset.inputfile; pset.inputfile = filename; result = MainLoop(fd); fclose(fd); - pset.inputfile = NULL; + pset.inputfile = oldfilename; return (result == EXIT_SUCCESS); } diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c index a444e5bd7a..6cfe06e3d1 100644 --- a/src/interfaces/libpq/fe-connect.c +++ b/src/interfaces/libpq/fe-connect.c @@ -7,7 +7,7 @@ * * * IDENTIFICATION - * $Header: /cvsroot/pgsql/src/interfaces/libpq/fe-connect.c,v 1.113 2000/01/18 19:05:31 momjian Exp $ + * $Header: /cvsroot/pgsql/src/interfaces/libpq/fe-connect.c,v 1.114 2000/01/23 01:27:39 petere Exp $ * *------------------------------------------------------------------------- */ @@ -467,25 +467,6 @@ PQsetdbLogin(const char *pghost, const char *pgport, const char *pgoptions, else conn->dbName = strdup(dbName); - if (conn->dbName) - { - - /* - * if the database name is surrounded by double-quotes, then don't - * convert case - */ - if (*conn->dbName == '"') - { - strcpy(conn->dbName, conn->dbName + 1); - conn->dbName[strlen(conn->dbName) - 1] = '\0'; - } - else - for (i = 0; conn->dbName[i]; i++) - if (isascii((unsigned char) conn->dbName[i]) && - isupper(conn->dbName[i])) - conn->dbName[i] = tolower(conn->dbName[i]); - } - if (error) { conn->status = CONNECTION_BAD;