more restriction for fretful users. The current PG allow define only
NO-CREATE-DB and NO-CREATE-USER restriction, but for some users I need
NO-CREATE-TABLE and NO-LOCK-TABLE.
This patch add to current code NOCREATETABLE and NOLOCKTABLE feature:
CREATE USER username
[ WITH
[ SYSID uid ]
[ PASSWORD 'password' ] ]
[ CREATEDB | NOCREATEDB ] [ CREATEUSER | NOCREATEUSER ]
-> [ CREATETABLE | NOCREATETABLE ] [ LOCKTABLE | NOLOCKTABLE ]
...etc.
If CREATETABLE or LOCKTABLE is not specific in CREATE USER command,
as default is set CREATETABLE or LOCKTABLE (true).
A user with NOCREATETABLE restriction can't call CREATE TABLE or
SELECT INTO commands, only create temp table is allow for him.
Karel
CPP) to create platform independent files. Unfortunately, that means that
every config.status (or configure) run invariably causes a relink of the
postmaster and also that we can't put these files in the distribution
(usefully). So we make it a little smarter: when the output files already
exist and it notices that it would recreate them in identical form, it
doesn't touch them. In order to avoid re-running the make rule all the time
we update a timestamp file instead.
Update release_prep accordingly. Also make Gen_fmgrtab.sh use the awk that
is detected at configure time, not necessarily named `awk' and have it check
for exit statuses a little better.
In other news... Remove USE_LOCALE from the templates, it was set to `no'
everywhere anyway. Also remove YACC and YFLAGS from the templates, configure
is smart enough to find bison or yacc itself. Use AC_PROG_YACC for that
instead of the hand-crafted code. Do not set YFLAGS to `-d'. The make rules
that need this flag should explicitly invoke it. YFLAGS should be a user
variable. Update the makefiles to that effect.
direct pointer into the syscache entry for the type. In some cases
the syscache entry might get flushed before we are done using the
returned type name. This bug accounts for difficult-to-repeat
failures seen when INSERTs into columns of certain data types are
run in parallel with VACUUMs of system tables. There may be related
problems elsewhere --- we need to take a harder look at uses of
syscache data.
inputs have been converted to newstyle. This should go a long way towards
fixing our portability problems with platforms where char and short
parameters are passed differently from int-width parameters. Still
more to do for the Alpha port however.
That means you can now set your options in either or all of $PGDATA/configuration,
some postmaster option (--enable-fsync=off), or set a SET command. The list of
options is in backend/utils/misc/guc.c, documentation will be written post haste.
pg_options is gone, so is that pq_geqo config file. Also removed were backend -K,
-Q, and -T options (no longer applicable, although -d0 does the same as -Q).
Added to configure an --enable-syslog option.
changed all callers from TPRINTF to elog(DEBUG)
key call sites are changed, but most called functions are still oldstyle.
An exception is that the PL managers are updated (so, for example, NULL
handling now behaves as expected in plperl and plpgsql functions).
NOTE initdb is forced due to added column in pg_proc.
the oper field should be a valid Node structure so it can be dumped by
outfuncs.c without risk of coredump. (We had been using a raw pointer
to character string, which surely is NOT a valid Node.) This doesn't
cause any backwards compatibility problems for stored rules, since
raw unanalyzed parsetrees are never stored.
than not knowing what they are at all. Perhaps they should have their own
type category? Hard to say. In the meantime, doing it this way allows
SELECT 'unknown' || 'unknown' to continue being resolved as textcat,
instead of spitting out an ambiguous-operator error.
Add a random number generator and seed setter (random(), SET SEED)
Fix up the interval*float8 math to carry partial months
into the time field.
Add float8*interval so we have symmetry in the available math.
Fix the parser and define.c to accept SQL92 types as field arguments.
Fix the parser to accept SQL92 types for CREATE TYPE, etc. This is
necessary to allow...
Bit/varbit support in contrib/bit cleaned up to compile and load
cleanly. Still needs some work before final release.
Implement the "SOME" keyword as a synonym for "ANY" per SQL92.
Implement ascii(text), ichar(int4), repeat(text,int4) to help
support the ODBC driver.
Enable the TRUNCATE() function mapping in the ODBC driver.
single integers, and lists of names, without surrounding them with quotes.
Remove all tokens which are defined as operators from ColID and ColLabel
to avoid precedence confusion. Thanks to Tom Lane for catching this.
Move CREATE FUNCTION/WITH clause to end of statement to get around
shift/reduce conflicts with type names containing "WITH".
Add lots of tokens as allowed ColId's and/or ColLabel's,
so this should be a complete set for the v7.0 release.
keys lists of Constraint nodes. This eliminates a type pun that would
probably have caused trouble someday, and eliminates circular references
in the parsetree that were causing trouble now.
Also, change parser's uses of strcasecmp() to strcmp(). Since scan.l
has downcased any unquoted identifier, it is never correct to check an
identifier with strcasecmp() in the parser. For example,
CREATE TABLE FOO (f1 int, UNIQUE("F1"));
was accepted, which is wrong, and xlateSqlFunc did more than it should:
select datetime();
ERROR: Function 'timestamp()' does not exist
(good)
select "DateTime"();
ERROR: Function 'timestamp()' does not exist
(bad)
had already been transformed. This led to failure in examples like
UPDATE table SET fld = (SELECT ...). Repair this, and revise the
comments to explain that transformExpr has to be robust against this
condition. Someday we might want to fix the callers so that
transformExpr is never invoked on its own output, but that someday
is not today.
In function parsing, try for an actual function of the given name and
input types before trying to interpret the function call as a type
coercion request, rather than after. Before, a function that had the
same name as a type and operated on a binary-compatible type wouldn't
get invoked. Also, cross-pollinate between func_select_candidates and
oper_select_candidates to ensure that they use as nearly the same
resolution rules as possible. A few other minor code cleanups too.
problem could be lack of parentheses. This addresses cases like
X UserOp UserOp Y, which will be parsed as (X UserOp) UserOp Y,
whereas what likely was wanted was X UserOp (UserOp Y).
16-Mar-00: trailing + or - is not part of the operator unless the operator
also contains characters not present in SQL92-defined operators. This
solves the 'X=-Y' problem without unduly constraining users' choice of
operator names --- in particular, no existing Postgres operator names
become invalid.
Also, remove processing of // comments, as agreed in the same thread.
running gcc and HP's cc with warnings cranked way up. Signed vs unsigned
comparisons, routines declared static and then defined not-static,
that kind of thing. Tedious, but perhaps useful...
actually a type-coercion problem. If you have a function defined on
class A, and class B inherits from A, then the function ought to work
on class B as well --- but coerce_type didn't know that. Now it does.
after trying to resolve the item as an input-column name. This allows us
to be compliant with the SQL92 spec for queries that fall within the spec,
while still accepting the same out-of-spec queries as 6.5 did. You'll only
lose if there is an output column name that is the same as an input
column name, but doesn't refer to the same value. 7.0 will interpret
such a GROUP BY spec differently than 6.5 did. No way around that, because
6.5 was clearly not spec compliant.
Implement TIME WITH TIME ZONE type (timetz internal type).
Remap length() for character strings to CHAR_LENGTH() for SQL92
and to remove the ambiguity with geometric length() functions.
Keep length() for character strings for backward compatibility.
Shrink stored views by removing internal column name list from visible rte.
Implement min(), max() for time and timetz data types.
Implement conversion of TIME to INTERVAL.
Implement abs(), mod(), fac() for the int8 data type.
Rename some math functions to generic names:
round(), sqrt(), cbrt(), pow(), etc.
Rename NUMERIC power() function to pow().
Fix int2 factorial to calculate result in int4.
Enhance the Oracle compatibility function translate() to work with string
arguments (from Edwin Ramirez).
Modify pg_proc system table to remove OID holes.
YY_READ_BUF_SIZE, which turns out to have nothing to do with buffer size.
It's just a totally arbitrary upper limit on how much data myinput() is
asked for at one time.
gone, replaced by plain a_expr. The few places where we needed to
distinguish NULL from a_expr are now handled by tests inside the actions
rather than by separate productions. This allows us to accept queries
like 'SELECT 1 + NULL' without requiring parentheses around the NULL.
coercion code. I'm beginning to wonder why we have separate candidate
selection routines for functions, operators, and aggregates --- shouldn't
this code all be unified? But meanwhile,
SELECT 'a' LIKE 'a';
finally works; the code for dealing with unknown input types for operators
was pretty busted.
per pghackers discussion around 20-Feb. Also add specific error messages
for unterminated comments and unterminated quoted strings. These things
are nonissues for input coming from psql, but they do matter for input
coming from other front ends.
as independent clauses in the grammar. analyze.c takes care of putting
the data where it belongs and complaining about invalid combinations.
Also, make TEMP (and TEMPORARY) non-reserved words.
failures. Fix some outright bugs too, including a reference to
uninitialized memory that would cause failures like this one:
select -('1234567890.1234567'::text);
ERROR: Unable to locate type oid 2139062143 in catalog
such as bpchar(char_expression, N), and pull out the attrtypmod that
the function is coercing to. This allows correct deduction of the
column type in examples such as
CREATE VIEW v AS SELECT f1::char(8) FROM tbl;
Formerly we labeled v's column as char-of-unknown-length not char(8).
Also, this change causes the parser not to insert a redundant length
coercion function if the user has explicitly casted an INSERT or UPDATE
expression to the right length.
and produce either FLOAT8 or NUMERIC output depending on whether the
value fits in a float8 or not. This is almost back to the way the
code was before I changed T_Float, but there is a critical difference:
now, when a numeric constant doesn't fit in float8, it will be treated
as type NUMERIC instead of type UNKNOWN.
integers) to be strings instead of 'double'. We convert from string form
to internal representation only after type resolution has determined the
correct type for the constant. This eliminates loss-of-precision worries
and gets rid of the change in behavior seen at 17 digits with the
previous kluge.
as representing a type coercion request in more cases than we did before.
It will work now whenever no underlying function is required, ie if the
coercion is binary-compatible or if the argument is a previously untyped
string constant. Otherwise, you still need a real function to exist.
represent the result of a binary-compatible type coercion. At runtime
it just evaluates its argument --- but during type resolution, exprType
will pick up the output type of the RelabelType node instead of the type
of the argument. This solves some longstanding problems with dropped
type coercions, an example being 'select now()::abstime::int4' which
used to produce date-formatted output, not an integer, because the
coercion to int4 was dropped on the floor.
agg_select_candidate, which could cause them to keep more candidates
than they should and thus fail to select a single match. I had
previously fixed the identical bug in oper_select_candidate, but
didn't realize that the same error was repeated over here.
Also, repair func_select_candidate's curious notion that it could
scribble on the input type-OID vector. That was causing failure to
apply necessary type coercion later on, leading to malfunction of
examples such as select date('now').
a few bricks shy of a load concerning knowing all the date/time types.
This is real bad because it interferes with func_select_candidate()'s
willingness to disambiguate functions --- func_select_candidate() will
punt unless all the available choices have the same type category.
I think this whole mechanism needs redesigned, but in the meantime
this is a needed patch.
interpret a column name as an output column alias (targetlist AS name),
ather than a real column name as it ought to. According to the spec,
only ORDER BY should look at output column names. I left in GROUP BY's
willingness to use an output column number ('GROUP BY 2'), even though
this is also contrary to the spec --- again, only ORDER BY is supposed
to accept that. But there is no possible reason to want to GROUP BY
an integer constant, so keeping this old behavior won't break any
SQL-compliant queries. DISTINCT ON will behave the same as GROUP BY.
Change numerology regress test, which depended on the incorrect
behavior.
equivalent now, which should make Windows and Mac clients happier.
Also fix failure to handle SQL comments between segments of a multiline
quoted literal.
Transform datetime and timespan into timestamp and interval.
Deprecate datetime and timespan, though translate to new types in gram.y.
Transform all datetime and timespan catalog entries into new types.
Make "INTERVAL" reserved word allowed as a column identifier in gram.y.
Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility
routines for all date/time types.
date.{h,c} now deals with date, time types.
timestamp.{h,c} now deals with timestamp, interval types.
nabstime.{h,c} now deals with abstime, reltime, tinterval types.
Make NUMERIC a known native type for purposes of type coersion. Not tested.
SELECT a FROM t1 tx (a);
Allow join syntax, including queries like
SELECT * FROM t1 NATURAL JOIN t2;
Update RTE structure to hold column aliases in an Attr structure.
Add "SESSION_USER" as SQL92 keyword; equivalent to CURRENT_USER for now.
Implement column aliases (aka correlation names) and more join syntax.
Fix up indenting and tabbing.
Added constraint dumping capability to pg_dump (also from Stephan)
Fixed DROP TABLE -> RelationBuildTriggers: 2 record(s) not found for rel
error.
Fixed little error in gram.y I made the last days.
Jan
Initdb help correction
Changed end/abort to commit/rollback and changed related notices
Commented out way old printing functions in libpq
Fixed a typo in alter table / alter column
SELECT DISTINCT ON (expr [, expr ...]) targetlist ...
and there is a check to make sure that the user didn't specify an ORDER BY
that's incompatible with the DISTINCT operation.
Reimplement nodeUnique and nodeGroup to use the proper datatype-specific
equality function for each column being compared --- they used to do
bitwise comparisons or convert the data to text strings and strcmp().
(To add insult to injury, they'd look up the conversion functions once
for each tuple...) Parse/plan representation of DISTINCT is now a list
of SortClause nodes.
initdb forced by querytree change...
allows casts without specific length requirements to continue to work
as they did before; that is, x::char will not truncate the value of x,
whereas x::char(1) will. Likewise for NUMERIC precision/scale.
The column length defaults of char(1) and numeric(30,6) are now inserted
in analyze.c's processing of CREATE TABLE.
SQL cast constructs can be performed during expression transformation
instead of during parsing. This allows constructs like x::numeric(9,2)
and x::int2::float8 to behave as one would expect.
* Let unprivileged users change their own passwords.
* The password is now an Sconst in the parser, which better reflects its text datatype and also
forces users to quote them.
* If your password is NULL you won't be written to the password file, meaning you can't connect
until you have a password set up (if you use password authentication).
* When you drop a user that owns a database you get an error. The database is not gone.
SELECT null::text;
SELECT int4fac(null);
work as expected now. In some cases a NULL must be surrounded by
parentheses:
SELECT 2 + null; fails
SELECT 2 + (null); OK
This is a grammatical ambiguity that seems difficult to avoid. Other
than that, NULLs seem to behave about like you'd expect. The internal
implementation is that NULL constants are typed as UNKNOWN (like
untyped string constants) until the parser can deduce the right type.
>go about this. That will risk breaking existing applications that use
>those names as column names.
>
>It should actually almost work to write sq.nextval as things stand,
>because Postgres has for a long time considered table.function and
>function(table) to be interchangeable notations for certain kinds of
>functions. nextval doesn't seem to be one of that kind of function,
>at the moment. I'd suggest leaving the grammar as it was, and taking a
>look at ParseFuncOrColumn in parse_func.c to see if you can't persuade
>it to accept the sequence functions in that style.
OK, good point. I tried to implement it somewhere else and ended up
extending transformAttr. Attached you'll find the patch.
Jeroen van Vianen
didn't have time for documentation yet, but I'll write some. There are
still some things to work out what happens when you alter or drop users,
but the group stuff in and by itself is done.
--
Peter Eisentraut Sernanders väg 10:115
anywhere from zero to two TODO items.
* Allow flag to control COPY input/output of NULLs
I got this:
COPY table .... [ WITH NULL AS 'string' ]
which does what you'd expect. The default is \N, otherwise you can use
empty strings, etc. On Copy In this acts like a filter: every data item
that looks like 'string' becomes a NULL. Pretty straightforward.
This also seems to be related to
* Make postgres user have a password by default
If I recall this discussion correctly, the problem was actually that the
default password for the postgres (or any) user is in fact "\N", because
of the way copy is used. With this change, the file pg_pwd is copied out
with nulls as empty strings, so if someone doesn't have a password, the
password is just '', which one would expect from a new account. I don't
think anyone really wants a hard-coded default password.
Peter Eisentraut Sernanders väg 10:115
yet, but at least we can give a better error message:
regression=> select count(distinct f1) from int4_tbl;
ERROR: aggregate(DISTINCT ...) is not implemented yet
instead of 'parser: parse error at or near distinct'.
(which are palloc'd) instead of DLLists (which are malloc'd). Not very
significant, since this routine seldom has anything useful to do, but
a leak is a leak...
This one should work much better than the one I sent in previously. The
functionality is the same, but the patch was missing one file resulting
in
the compilation failing. The docs also received a minor fix.
Peter Eisentraut Sernanders väg 10:115
Make all system indexes unique.
Make all cache loads use system indexes.
Rename *rel to *relid in inheritance tables.
Rename cache names to be clearer.
table defaults or rules: translate them to a function call so that
parse_coerce doesn't reduce them to a date or time constant immediately.
Also, eliminate a lot of redundancy in the expression grammar by
defining a new nonterminal com_expr, which contains all the productions
that can be shared by a_expr and b_expr.
subselects can only appear on the righthand side of a binary operator.
That's still true for quantified predicates like x = ANY (SELECT ...),
but a subselect that delivers a single result can now appear anywhere
in an expression. This is implemented by changing EXPR_SUBLINK sublinks
to represent just the (SELECT ...) expression, without any 'left hand
side' or combining operator --- so they're now more like EXISTS_SUBLINK.
To handle the case of '(x, y, z) = (SELECT ...)', I added a new sublink
type MULTIEXPR_SUBLINK, which acts just like EXPR_SUBLINK used to.
But the grammar will only generate one for a multiple-left-hand-side
row expression.
The following patch extends the COMMENT ON functionality to the
rest of the database objects beyond just tables, columns, and views. The
grammer of the COMMENT ON statement now looks like:
COMMENT ON [
[ DATABASE | INDEX | RULE | SEQUENCE | TABLE | TYPE | VIEW ] <objname>
|
COLUMN <relation>.<attribute> |
AGGREGATE <aggname> <aggtype> |
FUNCTION <funcname> (arg1, arg2, ...) |
OPERATOR <op> (leftoperand_typ rightoperand_typ) |
TRIGGER <triggername> ON relname>
Mike Mascari
(mascarim@yahoo.com)
This patch fix a TODO list item.
* require SELECT DISTINCT target list to have all ORDER BY columns
example
ogawa=> select distinct x from t1 order by y;
ERROR: ORDER BY columns must appear in SELECT DISTINCT target list
---
Atsushi Ogawa
boundary-condition bug in myinput() which caused flex scanner to fail
on tokens larger than a bufferload. Turns out flex doesn't want null-
terminated input ... and if it gives you a 1-character buffer, you'd
better supply a character, not a null, lest you be thought to be
reporting end of input.
>From the ORACLE 7 SQL Language Reference Manual:
-----------------------------------------------------
COMMENT
Purpose:
To add a comment about a table, view, snapshot, or
column into the data dictionary.
Prerequisites:
The table, view, or snapshot must be in your own
schema
or you must have COMMENT ANY TABLE system privilege.
Syntax:
COMMENT ON [ TABLE table ] |
[ COLUMN table.column] IS 'text'
You can effectively drop a comment from the database
by setting it to the empty string ''.
-----------------------------------------------------
Example:
COMMENT ON TABLE workorders IS
'Maintains base records for workorder information';
COMMENT ON COLUMN workorders.hours IS
'Number of hours the engineer worked on the task';
to drop a comment:
COMMENT ON COLUMN workorders.hours IS '';
The current patch will simply perform the insert into
pg_description, as per the TODO. And, of course, when
the table is dropped, any comments relating to it
or any of its attributes are also dropped. I haven't
looked at the ODBC source yet, but I do know from
an ODBC client standpoint that the standard does
support the notion of table and column comments.
Hopefully the ODBC driver is already fetching these
values from pg_description, but if not, it should be
trivial.
Hope this makes the grade,
Mike Mascari
(mascarim@yahoo.com)
mentioned in FROM but not elsewhere in the query: such tables should be
joined over anyway. Aside from being more standards-compliant, this allows
removal of some very ugly hacks for COUNT(*) processing. Also, allow
HAVING clause without aggregate functions, since SQL does. Clean up
CREATE RULE statement-list syntax the same way Bruce just fixed the
main stmtmulti production.
CAUTION: addition of a field to RangeTblEntry nodes breaks stored rules;
you will have to initdb if you have any rules.
expressions in CREATE TABLE. There is no longer an emasculated expression
syntax for these things; it's full a_expr for constraints, and b_expr
for defaults (unfortunately the fact that NOT NULL is a part of the
column constraint syntax causes a shift/reduce conflict if you try a_expr.
Oh well --- at least parenthesized boolean expressions work now). Also,
stored expression for a column default is not pre-coerced to the column
type; we rely on transformInsertStatement to do that when the default is
actually used. This means "f1 datetime default 'now'" behaves the way
people usually expect it to.
BTW, all the support code is now there to implement ALTER TABLE ADD
CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't
actually teach ALTER TABLE to call it, but it wouldn't be much work.
not just C, so that ISCACHABLE attribute can be specified for user-defined
functions. Get rid of ParamString node type, which wasn't actually being
generated by gram.y anymore, even though define.c thought that was what
it was getting. Clean up minor bug in dfmgr.c (premature heap_close).
Implements the CREATE CONSTRAINT TRIGGER and SET CONSTRAINTS commands.
TODO:
Generic builtin trigger procedures
Automatic execution of appropriate CREATE CONSTRAINT... at CREATE TABLE
Support of new trigger type in pg_dump
Swapping of huge # of events to disk
Jan
functions. One problem that I have encountered with the function
manager is that it does not allow the user to define type conversion
functions that convert between user types. For instance if mytype1,
mytype2, and mytype3 are three Postgresql user types, and if I wish to
define Postgresql conversion functions like
I run into problems, because the Postgresql dynamic loader would look
for a single link symbol, mytype3, for both pieces of object code. If
I just change the name of one of the Postgresql functions (to make the
symbols distinct), the automatic type conversion that Postgresql uses,
for example, when matching operators to arguments no longer finds the
type conversion function.
The solution that I propose, and have implemented in the attatched
patch extends the CREATE FUNCTION syntax as follows. In the first case
above I use the link symbol mytype2_to_mytype3 for the link object
that implements the first conversion function, and define the
Postgresql operator with the following syntax
The patch includes changes to the parser to include the altered
syntax, changes to the ProcedureStmt node in nodes/parsenodes.h,
changes to commands/define.c to handle the extra information in the AS
clause, and changes to utils/fmgr/dfmgr.c that alter the way that the
dynamic loader figures out what link symbol to use. I store the
string for the link symbol in the prosrc text attribute of the pg_proc
table which is currently unused in rows that reference dynamically
loaded
functions.
Bernie Frankpitt
behavior as it was, apart from forbidding minus-terminated
operators. Seems that I have to break the habit of doing before
thinking properly :-/ The point is that my second patch breaks
constructs like a & b or a ! b. This patch is to be applied
instead of any of two other today's patches.
Leon
additional argument specifying the kind of lock to acquire/release (or
'NoLock' to do no lock processing). Ensure that all relations are locked
with some appropriate lock level before being examined --- this ensures
that relevant shared-inval messages have been processed and should prevent
problems caused by concurrent VACUUM. Fix several bugs having to do with
mismatched increment/decrement of relation ref count and mismatched
heap_open/close (which amounts to the same thing). A bogus ref count on
a relation doesn't matter much *unless* a SI Inval message happens to
arrive at the wrong time, which is probably why we got away with this
sloppiness for so long. Repair missing grab of AccessExclusiveLock in
DROP TABLE, ALTER/RENAME TABLE, etc, as noted by Hiroshi.
Recommend 'make clean all' after pulling this update; I modified the
Relation struct layout slightly.
Will post further discussion to pghackers list shortly.
Almost worked before, but forgot one place to check.
Reported by Tatsuo Ishii.
Still does not do the right thing if inserting into a non-string target
column. Should look for a type coersion later, but doesn't.
corrects flex myinput() routine so that it doesn't assume there is only
one bufferload of data. We still have the issue of getting rid of
YY_USES_REJECT so that the scanner can cope with tokens larger than its
initial buffer size.
last loop which would return the *first* surviving-to-that-point candidate
regardless of which one actually passed the test. This was producing
such curious results as 'oid % 2' getting translated to 'int2(oid) % 2'.
documented intepretation of the lefthand and oper fields. Fix a number of
obscure problems while at it --- for example, the old code failed if the parser
decided to insert a type-coercion function just below the operator of a
SubLink.
CAUTION: this will break stored rules that contain subplans. You may
need to initdb.
match then it tried for a self-commutative operator with the reversed input
data types. This is pretty silly; there could never be such an operator,
except maybe in binary-compatible-type scenarios, and we have oper_inexact
for that. Besides which, the oprsanity regress test would complain about
such an operator. Remove nonfunctional code and simplify routine calling
convention accordingly.
and fix_opids processing to a single recursive pass over the plan tree
executed at the very tail end of planning, rather than haphazardly here
and there at different places. Now that tlist Vars do not get modified
until the very end, it's possible to get rid of the klugy var_equal and
match_varid partial-matching routines, and just use plain equal()
throughout the optimizer. This is a step towards allowing merge and
hash joins to be done on expressions instead of only Vars ...
sort order down into planner, instead of handling it only at the very top
level of the planner. This fixes many things. An explicit sort is now
avoided if there is a cheaper alternative (typically an indexscan) not
only for ORDER BY, but also for the internal sort of GROUP BY. It works
even when there is no other reason (such as a WHERE condition) to consider
the indexscan. It works for indexes on functions. It works for indexes
on functions, backwards. It's just so cool...
CAUTION: I have changed the representation of SortClause nodes, therefore
THIS UPDATE BREAKS STORED RULES. You will need to initdb.
optimizer rather than parser. This has many advantages, such as not
getting fooled by chance uses of operator names ~ and ~~ (the operators
are identified by OID now), and not creating useless comparison operations
in contexts where the comparisons will not actually be used as indexquals.
The new code also recognizes exact-match LIKE and regex patterns, and
produces an = indexqual instead of >= and <=.
This change does NOT fix the problem with non-ASCII locales: the code
still doesn't know how to generate an upper bound indexqual for non-ASCII
collation order. But it's no worse than before, just the same deficiency
in a different place...
Also, dike out loc_restrictinfo fields in Plan nodes. These were doing
nothing useful in the absence of 'expensive functions' optimization,
and they took a considerable amount of processing to fill in.
support, but which the grammar was accepting. Also, fix several bugs
having to do with failure to copy fields up from a subselect to a select
or insert node.
of the SELECT part of the statement is just like a plain SELECT. All
INSERT-specific processing happens after the SELECT parsing is done.
This eliminates many problems, e.g. INSERT ... SELECT ... GROUP BY using
the wrong column labels. Ensure that DEFAULT clauses are coerced to
the target column type, whether or not stored clause produces the right
type. Substantial cleanup of parser's array support.
creates a reduce/reduce conflict, which I resolved by changing the
'AexprConst -> Typename Sconst' rule to 'AexprConst -> SimpleTypename Sconst'.
In other words, a subscripted type declaration can't be used in that
syntax any longer. This seems a small price to pay for not having to
qualify subscripted columns anymore.
Other cleanups: rename res_target_list to update_target_list, and remove
productions for variants that are not legal in an UPDATE target list;
rename res_target_list2 to plain target_list; delete position_expr
in favor of using b_expr in that production; merge opt_indirection
into attr nonterminal, since there are no places where an unsubscripted
attr is wanted; fix typos in Param support; change case_arg so that
an arbitrary a_expr is allowed, not only a column name.
is parse_aggs.c. This fixes its failure to cope with (at least) CaseExpr
and ArrayRef nodes, which is the reason why both of these fail in 6.5:
select coalesce(f1,0) from int4_tbl group by f1;
ERROR: Illegal use of aggregates or non-group column in target list
select sentence.words[0] from sentence group by sentence.words[0];
ERROR: Illegal use of aggregates or non-group column in target list
The array case still fails, but at least it's not parse_agg's fault
anymore ... considering that we now support CASE officially, I think
it's important to fix the first example ...
a non-leading % would be put into the >=/<= patterns. Also, repair
longstanding confusion about whether %% means a literal %%. The SQL92
doesn't say any such thing, and textlike() knows that, but gram.y didn't.
aggregate functions, as in
select a, b from foo group by a;
The ungrouped reference to b is not kosher, but formerly we neglected to
check this unless there was an aggregate function somewhere in the query.
SelectStmt and CursorStmt tried to parse FOR UPDATE ... / FOR READ ONLY.
Cursor now checks that it is read only by looking at forUpdate of Query.
SelectStmt handles FOR READ ONLY too.
Jan
will pass through rather than spitting up. This is necessary to handle
cases where coerce_type causes a subexpression to be retransformed, as in
SELECT count(*) + 1.0 FROM table
lists are now plain old garden-variety Lists, allocated with palloc,
rather than specialized expansible-array data allocated with malloc.
This substantially simplifies their handling and eliminates several
sources of memory leakage.
Several basic types of erroneous queries (syntax error, attempt to
insert a duplicate key into a unique index) now demonstrably leak
zero bytes per query.
and lock syntax as fully parsed tokens.
Two keywords for isolation are non-reserved SQL92
(COMMITTED, SERIALIZABLE).
All other new keywords are non-reserved Postgres (not SQL92)
(ACCESS, EXCLUSIVE, MODE, SHARE).
Add syntax to allow CREATE [GLOBAL|LOCAL] TEMPORARY TABLE, throwing an
error if GLOBAL is specified.
constraints. Reported by Tom Lane.
Now, check for duplicate indices and retain the one which is a primary-key.
Adjust elog NOTICE messages to surround table and column names with single
quotes.
been applied. The patches are in the .tar.gz attachment at the end:
varchar-array.patch this patch adds support for arrays of bpchar() and
varchar(), which where always missing from postgres.
These datatypes can be used to replace the _char4,
_char8, etc., which were dropped some time ago.
block-size.patch this patch fixes many errors in the parser and other
program which happen with very large query statements
(> 8K) when using a page size larger than 8192.
This patch is needed if you want to submit queries
larger than 8K. Postgres supports tuples up to 32K
but you can't insert them because you can't submit
queries larger than 8K. My patch fixes this problem.
The patch also replaces all the occurrences of `8192'
and `1<<13' in the sources with the proper constants
defined in include files. You should now never find
8192 hardwired in C code, just to make code clearer.
--
Massimo Dal Zotto
expression context (ie, not at the top level of a WHERE clause). Examples
like this one work now:
SELECT name, value FROM t1 as touter WHERE
(value/(SELECT AVG(value) FROM t1 WHERE name = touter.name)) > 0.75;
delete the default argument from the node. This prevents the executor
from spitting up on the untransformed argument expression. Typical
failure was:
select (case f1 when 'val' then 'subst' else f1 end) from t1;
ERROR: copyObject: don't know how to copy 704
records using a sub form, i.e. entering a new order/orderlines or master
and
detail tables. The problem is caused by a SQL statement that Access97
makes
involving NULL. The syntax that fails is "column_name" = NULL. The
following attachment was provided by -Jose'-. It contains a very small
enhancement to gram.y that will allow Access97 to work properly with sub
forms. Can this enhancement be added to release 6.5?
<<gram.patch>>
Thanks, Michael
Ok. I made patches replacing all of "#if FALSE" or "#if 0" to "#ifdef
NOT_USED" for current. I have tested these patches in that the
postgres binaries are identical.
I search in the planner for the '\xFF' appending.
Finally I found in MakeIndexable() in gram.y
Attach a patch which removes the "<=" test in USE_LOCALE,
might make some queries a bit slower for us "locale-heads",
BUT correct result is more important.
regards,
--
-----------------
Göran Thyni
Included patches fix a portability problem of unsetenv() used in
6.4.2 multi-byte support. unsetenv() is only avaliable on FreeBSD and
Linux so I decided to replace with putenv().
a field was labelled as a primary key, the system automatically
created a unique index on the field. This patch extends it so
that the index has the indisprimary field set. You can pull a list
of primary keys with the followiing select.
SELECT pg_class.relname, pg_attribute.attname
FROM pg_class, pg_attribute, pg_index
WHERE pg_class.oid = pg_attribute.attrelid AND
pg_class.oid = pg_index.indrelid AND
pg_index.indkey[0] = pg_attribute.attnum AND
pg_index.indisunique = 't';
There is nothing in this patch that modifies the template database to
set the indisprimary attribute for system tables. Should they be
changed or should we only be concerned with user tables?
D'Arcy
INTERSECT and EXCEPT is available for postgresql-v6.4!
The patch against v6.4 is included at the end of the current text
(in uuencoded form!)
I also included the text of my Master's Thesis. (a postscript
version). I hope that you find something of it useful and would be
happy if parts of it find their way into the PostgreSQL documentation
project (If so, tell me, then I send the sources of the document!)
The contents of the document are:
-) The first chapter might be of less interest as it gives only an
overview on SQL.
-) The second chapter gives a description on much of PostgreSQL's
features (like user defined types etc. and how to use these features)
-) The third chapter starts with an overview of PostgreSQL's internal
structure with focus on the stages a query has to pass (i.e. parser,
planner/optimizer, executor). Then a detailed description of the
implementation of the Having clause and the Intersect/Except logic is
given.
Originally I worked on v6.3.2 but never found time enough to prepare
and post a patch. Now I applied the changes to v6.4 to get Intersect
and Except working with the new version. Chapter 3 of my documentation
deals with the changes against v6.3.2, so keep that in mind when
comparing the parts of the code printed there with the patched sources
of v6.4.
Here are some remarks on the patch. There are some things that have
still to be done but at the moment I don't have time to do them
myself. (I'm doing my military service at the moment) Sorry for that
:-(
-) I used a rewrite technique for the implementation of the Except/Intersect
logic which rewrites the query to a semantically equivalent query before
it is handed to the rewrite system (for views, rules etc.), planner,
executor etc.
-) In v6.3.2 the types of the attributes of two select statements
connected by the UNION keyword had to match 100%. In v6.4 the types
only need to be familiar (i.e. int and float can be mixed). Since this
feature did not exist when I worked on Intersect/Except it
does not work correctly for Except/Intersect queries WHEN USED IN
COMBINATION WITH UNIONS! (i.e. sometimes the wrong type is used for the
resulting table. This is because until now the types of the attributes of
the first select statement have been used for the resulting table.
When Intersects and/or Excepts are used in combination with Unions it
might happen, that the first select statement of the original query
appears at another position in the query which will be executed. The reason
for this is the technique used for the implementation of
Except/Intersect which does a query rewrite!)
NOTE: It is NOT broken for pure UNION queries and pure INTERSECT/EXCEPT
queries!!!
-) I had to add the field intersect_clause to some data structures
but did not find time to implement printfuncs for the new field.
This does NOT break the debug modes but when an Except/Intersect
is used the query debug output will be the already rewritten query.
-) Massive changes to the grammar rules for SELECT and INSERT statements
have been necessary (see comments in gram.y and documentation for
deatails) in order to be able to use mixed queries like
(SELECT ... UNION (SELECT ... EXCEPT SELECT)) INTERSECT SELECT...;
-) When using UNION/EXCEPT/INTERSECT you will get:
NOTICE: equal: "Don't know if nodes of type xxx are equal".
I did not have time to add comparsion support for all the needed nodes,
but the default behaviour of the function equal met my requirements.
I did not dare to supress this message!
That's the reason why the regression test for union will fail: These
messages are also included in the union.out file!
-) Somebody of you changed the union_planner() function for v6.4
(I copied the targetlist to new_tlist and that was removed and
replaced by a cleanup of the original targetlist). These chnages
violated some having queries executed against views so I changed
it back again. I did not have time to examine the differences between the
two versions but now it works :-)
If you want to find out, try the file queries/view_having.sql on
both versions and compare the results . Two queries won't produce a
correct result with your version.
regards
Stefan
destructions in 6.4 source using purify.
(1) parser/gram.y:fmtId()
It writes n+3 bytes into n+1 byte-long memory area if mixed case or
non-ascii identifiers given.
(2) catalog/index.c:
ATTRIBUTE_TUPLE_SIZE bytes are allocated but
sizeof(FormData_pg_attribute) bytes are written. Note that
ATTRIBUTE_TUPLE_SIZE is smaller than
sizeof(FormData_pg_attribute). (for example, on solaris 2.6,
Tatsuo Ishii
But it may be self-satisfied.
Please check my patch at the end of this posting.
Case 1. executor evaluates functions twice
Hiroshi Inoue
Inoue@tpf.co.jp
do not configure in the perl5 interface.
the perl5 interface needs to be installed under /usr/local/lib/perl5/*, which
is generally owned by root. This allows a non-root build/install with the
only root requirement being the make/install of hte perl5 stuff...
parameters. With it applied a function like
CREATE FUNCTION getname(oid8, int4) RETURNS name AS
'SELECT typname FROM pg_type WHERE oid = $1[$2]'
LANGUAGE 'sql';
is possible. Mainly I need this to enable array references in
expressions for PL/pgSQL. Complete regression test ran O.K.
Jan
Add "timestamp" to list of tokens in keywords.c.
Before, TIMESTAMP WITH TIME ZONE did not actually parser.
Reorder token lists to be more alphabetical.
Remove ARCHIVE keyword which was deprecated in v6.3.
Change DEFAULT NULL to send back a NULL pointer
rather than a string "NULL". This seems to work, where sending
the string led to type conversion problems (and probably the wrong
thing anyway).
rather than func_select_candidate().
Fix oper_select_candidate() to work with a single operator argument.
Repair left operator checking for null return from candidate list.
