varchar length.
Cleans up code so attlen is always length.
Removed varchar() hack added earlier.
Will fix bug in selecting varchar() fields, and varchar() can be
variable length.
and from SELECT ... INTO ... support code.
Allow NOT, IS NULL, IS NOT NULL in constraints.
Define unionall boolean flag in SubSelect structure.
Implement row descriptors: (a, b, c) = (x, y, z).
Change IS TRUE, IS FALSE, etc. to expressions using "=" rather than
function calls to istrue() or isfalse() to allow optimization.
Force type for TRUE and FALSE to bool.
Formerly allowed only single arguments.
Declare column constraints using the usual list mechanism rather
than explicit itemized lists.
Remove NOTNULL from default clause syntax (retain "NOT NULL").
NOTNULL is not SQL92; eventually remove it from expressions too?
Move ISNULL, NOTNULL to Postgres-specific token declarations.
Fix up tabs and indenting on new CREATE USER commands.
to NOTICE messages so that execution proceeds rather than halting.
These clauses are ignored as stated in the messages.
Allow NOT NULL UNIQUE syntax (both were allowed individually before).
Allow Postgres-style casting ("::") of non-constants.
Support SQL92 syntax for type coersion of strings (type 'typeval').
Example: "DATETIME 'now'". This works only for string constants and can
not replace the CAST and ::type syntax which behave identically in this
context.
Implement SET keyword = DEFAULT and SET TIME ZONE DEFAULT.
Re-enable JOIN= option in CREATE OPERATOR statement (damaged for v6.2).
Allow more SQL and/or Postgres reserved words as column identifiers
or, if there are shift/reduce problems, at least as column labels.
CURRENT_USER.
Add syntax for primary and foreign keys.
Change optional syntax in CREATE INDEX to avoid parsing conflict with
TIMESTAMP WITH TIME ZONE data type (use USING <class> rather than WITH...).
Decouple various categories of data type syntax to allow the most possible
non-ambiguous extensions to SQL92 for column names and labels. This should
make the parser a bit more understandable, or at least easier to find
where and how the data types are handled.
Support syntax for IN and EXISTS clauses with subselects.
Support SQL92 syntax for IS TRUE/IS FALSE/IS NOT TRUE/IS NOT FALSE.
Add SQL/92 types decimal and numeric (temporary for syntax support).
These types need more support in the backend to be really implemented,
and the parser will need to be changed at that time.
Adjust limits on precision parameters for FLOAT(p) to match IEEE-compliant
arithmetic. Perhaps these limits should be processor-specific or obtained
from system include files instead.
Add parsing for UNION and outer JOINs.
Implement SQL92 "WITH TIME ZONE".
Allow some reserved words as identifiers and column labels.
Clean up indentation and "orphan spaces and tabs".
To: pgsql-patches@postgreSQL.org
Subject: [PATCHES] DROP AGGREGATE gram.y typo...
Somehow I dropped a comma in the gram.y part (line 129) of my
patch for drop aggregate. Here's a correct patch for gram.y.
PS. I hope I got the right comma, manually applied :) (scrappy)
Subject: Re: [PATCHES] SET DateStyle patches
On Tue, 22 Apr 1997, Thomas Lockhart wrote:
> Some more patches! These (try to) finish implementing SET variable TO value
> for "DateStyle" (changed the name from simply "date" to be more descriptive).
> This is based on code from Martin and Bruce (?), which was easy to modify.
> The syntax is
>
> SET DateStyle TO 'iso'
> SET DateStyle TO 'postgres'
> SET DateStyle TO 'sql'
> SET DateStyle TO 'european'
> SET DateStyle TO 'noneuropean'
> SET DateStyle TO 'us' (same as "noneuropean")
> SET DateStyle TO 'default' (current same as "postgres,us")
>
> ("european" is just compared for the first 4 characters, and "noneuropean"
> is compared for the first 7 to allow less typing).
>
> Multiple arguments are allowed, so SET datestyle TO 'sql,euro' is valid.
>
> My mods also try to implement "SHOW variable" and "RESET variable", but
> that part just core dumps at the moment. I would guess that my errors
> are obvious to someone who knows what they are doing with the parser stuff,
> so if someone (Bruce and/or Martin??) could have it do the right thing
> we will have a more complete set of what we need.
>
> Also, I would like to have a floating point precision global variable to
> implement "SET precision TO 10" and perhaps "SET precision TO 10,2" for
> float8 and float4, but I don't know how to do that for integer types rather
> than strings. If someone is fixing the SHOW and RESET code, perhaps they can
> add some hooks for me to do the floats while they are at it.
>
> I've left some remnants of variable structures in the source code which
> I did not use in the interests of getting something working for v6.1.
> We'll have time to clean things up for the next release...
Subject: [HACKERS] Patch: SET var TO 'val'
Here is a patch that adds a "SET variable TO 'somevalue'" capability
to the parser, and then calls the SetPGVariable() function (which does
just issue a elog(NOTICE) to see whether it works).
That's the framework for adding timezone/date format/language/...
stuff.
Changes:
* Unique index capability works using the syntax 'create unique
index'.
* Duplicate OID's in the system tables are removed. I put
little scripts called 'duplicate_oids' and 'find_oid' in
include/catalog that help to find and remove duplicate OID's.
I also moved 'unused_oids' from backend/catalog to
include/catalog, since it has to be in the same directory
as the include files in order to work.
* The backend tries converting the name of a function or aggregate
to all lowercase if the original name given doesn't work (mostly
for compatibility with ODBC).
* You can 'SELECT NULL' to your heart's content.
* I put my _bt_updateitem fix in instead, which uses
_bt_insertonpg so that even if the new key is so big that
the page has to be split, everything still works.
* All literal references to system catalog OID's have been
replaced with references to define'd constants from the catalog
header files.
* I added a couple of node copy functions. I think this was a
preliminary attempt to get rules to work.
It adds a WITH OIDS option to the copy command, which allows
dumping and loading of oids.
If a copy command tried to load in an oid that is greater than
its current system max oid, the system max oid is incremented. No
checking is done to see if other backends are running and have cached
oids.
pg_dump as its first step when using the -o (oid) option, will
copy in a dummy row to set the system max oid value so as rows are
loaded in, they are certain to be lower than the system oid.
pg_dump now creates indexes at the end to speed loading
Submitted by: Bruce Momjian <maillist@candle.pha.pa.us>
This patch forces postgres95 to assume any floating-point value is a
float8. It removes the requirement that you cast all floating-point
constants to float8.
We can remove alot of casts in the regression test after we are sure
this works.
If I have missed anything, would someone let me know. I have tested
inserts of floating-point values into float8 fields, and it worked well.
Casting the number to float4 showed the same precision loss as previous
uncast values showed.
Submitted by: Bruce Momjian <maillist@candle.pha.pa.us>
I've enclosed two patches. The first affects Solaris compilability. The
bug stems from netdb.h (where MAXHOSTNAMELEN is defined on a stock
system). If the user has installed the header files from BIND 4.9.x,
there will be no definition of MAXHOSTNAMELEN. The patch will, if all
else fails, try to include <arpa/nameser.h> and set MAXHOSTNAMELEN to
MAXDNAME, which is 256 (just like MAXHOSTNAMELEN on a stock system).
The second patch adds aliases for "ISNULL" to "IS NULL" and likewise for
"NOTNULL" to "IS NOT NULL". I have not removed the postgres specific
ISNULL and NOTNULL. I noticed this on the TODO list, and figured it would
be easy to remove.
The full semantics are:
[ expression IS NULL ]
[ expression IS NOT NULL ]
--Jason
Submitted by: Jason Wright <jason@oozoo.vnet.net>
Previously Postgres95 wouldn't accept 'order by' clauses with fields
referred to as '<table>.<field>', e.g.:
select t1.field1, t2.field2 from table1 t1, table2 t2
order by t2.field2;
This syntax is required by the ODBC SQL spec.
Submitted by: Dan McGuirk <mcguirk@indirect.com>
While a normal SELECT statement can contain a GROUP BY clause, a cursor
declaration cannot. This was not the case in PG-1.0. Was there a good
reason why this was changed? Are cursors being phased out? Is there any way
to get data with just a SELECT (and without a DECLARE CURSOR ...)?
The patch below seems to fix things. If anyone can see a problem with it,
please let me know. Thanks.
Submitted by: David Smith <dasmith@perseus.tufts.edu>
Bruce Momjian
Marc G. Fournier
Thomas G. Lockhart
Vadim B. Mikheev