oprlsortop and oprrsortop links. There's still a bug involving
conflicting definitions for point @ path, but I'm not taking
responsibility for deciding which one is right...
Fixes a bug in the rule system that caused a crashing
backend when a join-view with calculated column is used
in subselect.
Modifies EXPLAIN to explain rewritten queries instead of
the plain SeqScan on a view. Rules can produce very deep
MORE
Jan.
Here are patches needed to complie under AIX 4.2.
I changed configure.in, pqcomm.c, config.h.in, and fe-connect.c.
Also I had to install flex because lex did not want to translate pgc.l.
is wrong and dangerous unless you are using contrib/string. We really
need a thorough look at the issue of making the backend and the FE/BE
protocols completely 8-bit-clean for string data, but that's a task
for some future release.
and make backend/libpq/pqcomm.c only try to lock the socket file when
the call exists. Also, change open-RDONLY to open-WRONLY; at least
on my platform, you can't get a write lock on a file you didn't open
for writing.
for against a just updated CVS tree. It contains
Partial new rewrite system that handles subselects, view
aggregate columns, insert into select from view, updates
with set col = view-value and select rules restriction to
view definition.
Updates for rule/view backparsing utility functions to
handle subselects correct.
New system views pg_tables and pg_indexes (where you can
see the complete index definition in the latter one).
Enabling array references on query parameters.
Bugfix for functional index.
Little changes to system views pg_rules and pg_views.
The rule system isn't a release-stopper any longer.
But another stopper is that I don't know if the latest
changes to PL/pgSQL (not already in CVS) made it compile on
AIX. Still wait for some response from Dave.
Jan
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
spin-locks. Notice that it's now inline assembler in s_lock.h,
rather than seperate code in s_lock.c. It also shrank a little
bit... Just rip out the S_LOCK() define and insert the tas() inline
function. Please let me know if there are any problems with it.
Jon Buller
1. The UnixWare tas macro was reformatted (by indent or it like?) which caused
it to break. The asm macro construct is very particular about the %mem
construct -- it has to start in column 1.
2. When compiling libpq++, g++ was used even if configure found the C++ com-
piler to be CC.
3. When compiling libpq++, '-Wno-error' was added to CXXFLAGS, even if the
compiler wasn't g++.
Billy G. Allie
before.
> Looks like a GNU-ism. I nice one, but still a GNU-ism.
Sorry, I didn't know it is a GNU extension. I have written this patch
which should fix the problem. Let me know if you still have problems.
Massimo Dal Zotto
Here is a new patch for libpq, to make it work on Win32 again (since
the latest modifications broke it a little).
Please also add the file "libpq.rc" to the interfaces/libpq directory.
This will allow version-stamping of the generated DLL file, so that
automatic install programs (and interested users) can determine
the version of the file. The file is currently set as "prerelease".
Before the release, somebody should change the line "FILEFLAGS
VS_FF_PRERELEASE" to "FILEFLAGS 0". That information should probably
go into toos\RELEASE_CHANGES.
The patch is against the cvs as of ~ 1998-08-26 14:30 CEST.
//Magnus
> these patches define the UNLISTEN sql command. The code already
> existed but it was unknown to the parser. Now it can be used
> like the listen command.
> You must make clean and delete gram.c and parser.h before make.
> sinval.patch
>
> fixes a problem in SI cache which causes table overflow if some
> backend is idle for a long time while other backends keep adding
> entries.
> It uses the new signal handling implemented in tprintf.patch.
> I have also increacasesed the max number of backends from 32 to 64
> and the table size from 1000 to 5000.
> I don't know if anybody is working on SI, but until another
> solution is found this patch fixes the problem. I have received
> messages from other people reporting the same problem which I
> fixed many months ago.
> sequence.patch
>
> adds the missing setval command to sequences. Owner of sequences
> can now set the last value to any value between min and max
> without recreating the sequence. This is useful after loading
> data from external files.
> ps-status.patch
>
> macros for ps status, used by postgres.c and utility.c.
> Unfortunately ps status is system dependent and the current
> code doesn't work on linux. The use of macros confines system
> dependency to into one file (ps-status.h). Users of other
> operating systems should check this code and submit new macros.
lock.patch
I have rewritten lock.c cleaning up the code and adding better
assert checking I have also added some fields to the lock and
xid tags for better support of user locks. There is also a new
function which returns an array of pids owning a lock.
I'm using this code from over six months and it works fine.
assert.patch
adds a switch to turn on/off the assert checking if enabled at compile
time. You can now compile postgres with assert checking and disable it
at runtime in a production environment.
patch is applied:
Rewrite rules on relation level work fine now.
Event qualifications on insert/update/delete rules work
fine now.
I added the new keyword OLD to reference the CURRENT
tuple. CURRENT will be removed in 6.5.
Update rules can reference NEW and OLD in the rule
qualification and the actions.
Insert/update/delete rules on views can be established to
let them behave like real tables.
For insert/update/delete rules multiple actions are
supported now. The actions can also be surrounded by
parantheses to make psql happy. Multiple actions are
required if update to a view requires updates to multiple
tables.
Regular users are permitted to create/drop rules on
tables they have RULE permissions for
(DefineQueryRewrite() is now able to get around the
access restrictions on pg_rewrite). This enables view
creation for regular users too. This required an extra
boolean parameter to pg_parse_and_plan() that tells to
set skipAcl on all rangetable entries of the resulting
queries. There is a new function
pg_exec_query_acl_override() that could be used by
backend utilities to use this facility.
All rule actions (not only views) inherit the permissions
of the event relations owner. Sample: User A creates
tables T1 and T2, creates rules that log
INSERT/UPDATE/DELETE on T1 in T2 (like in the regression
tests for rules I created) and grants ALL but RULE on T1
to user B. User B can now fully access T1 and the
logging happens in T2. But user B cannot access T2 at
all, only the rule actions can. And due to missing RULE
permissions on T1, user B cannot disable logging.
Rules on the attribute level are disabled (they don't
work properly and since regular users are now permitted
to create rules I decided to disable them).
Rules on select must have exactly one action that is a
select (so select rules must be a view definition).
UPDATE NEW/OLD rules are disabled (still broken, but
triggers can do it).
There are two new system views (pg_rule and pg_view) that
show the definition of the rules or views so the db admin
can see what the users do. They use two new functions
pg_get_ruledef() and pg_get_viewdef() that are builtins.
The functions pg_get_ruledef() and pg_get_viewdef() could
be used to implement rule and view support in pg_dump.
PostgreSQL is now the only database system I know, that
has rewrite rules on the query level. All others (where I
found a rule statement at all) use stored database
procedures or the like (triggers as we call them) for
active rules (as some call them).
Future of the rule system:
The now disabled parts of the rule system (attribute
level, multiple actions on select and update new stuff)
require a complete new rewrite handler from scratch. The
old one is too badly wired up.
After 6.4 I'll start to work on a new rewrite handler,
that fully supports the attribute level rules, multiple
actions on select and update new. This will be available
for 6.5 so we get full rewrite rule capabilities.
Jan
if MULTIBYTE is not enabled. So be sure to run initdb.
o these patches are made against the latest source tree (after
Bruce's massive patch, I think) BTW, I noticed that after running
regression, the oid field of pg_type seems disappeared.
regression=> select oid from pg_type; ERROR: attribute
'oid' not found
this happens after the constraints test. This occures with/without
my patches. strange...
o pg_database_mb.h, pg_class_mb.h, pg_attribute_mb.h are no longer
used, and shoud be removed.
o GetDatabaseInfo() in utils/misc/database.c removed (actually in
#ifdef 0). seems nobody uses.
t-ishii@sra.co.jp
is a working 64-bit-int type available.
In playing around with it on my machine, I found that gcc provides
perfectly fine support for "long long" arithmetic ... but sprintf()
and sscanf(), which are system-supplied, don't work :-(. So the
autoconf test program does a cursory test on them too.
If we find that a lot of systems are like this, it might be worth
the trouble to implement binary<->ASCII conversion of int64 ourselves
rather than relying on sprintf/sscanf to handle the data type.
regards, tom lane
Summary of changes:
In pqcomm.h, use the SUN_LEN macro if it is defined to calculate
the size of the sockaddr_un structure.
In unixware.h, drop the use of the UNIXWARE macro. Everything can
be handled with the USE_UNIVEL_CC and DISABLE_COMPLEX_MACRO macros.
In s_lock.h, remove the reference to the UNIXWARE macro (see above).
In the unixware template, add the YFLAGS:-d line.
In various makefile templates, add (or cleanup) unixware and univel
port specific information.
-- Billy G. Allie
no longer returns buffer pointer, can be gotten from scan;
descriptor; bootstrap can create multi-key indexes;
pg_procname index now is multi-key index; oidint2, oidint4, oidname
are gone (must be removed from regression tests); use System Cache
rather than sequential scan in many places; heap_modifytuple no
longer takes buffer parameter; remove unused buffer parameter in
a few other functions; oid8 is not index-able; remove some use of
single-character variable names; cleanup Buffer variables usage
and scan descriptor looping; cleaned up allocation and freeing of
tuples; 18k lines of diff;
I have attached a patch to allow GROUP BY and/or ORDER BY function or
expressions. Note worthy items:
1. The expression or function need not be in the target list.
Example:
SELECT name FROM foo GROUP BY lower(name);
2. Simplified the grammar to use expressions only.
3. Cleaned up earlier patch in this area to make use of existing
utility functions.
3. Reduced some of the members in the SortGroupBy parse node. The
original data members were redundant with the new expression node.
(MUST do a "make clean" now)
4. Added a new parse node "JoinUsing". The JOIN USING clause was
overloading this SortGroupBy structure. With the afore mentioned
reduction of members, the two clauses lost all their commonality.
5. A bug still exist where, if a function or expression is GROUPed BY,
and an aggregate function does not include a attribute from the
expression or function, the backend crashes. (or something like
that) The bug pre-dates this patch. Example:
SELECT lower(a) AS lowcase, count(b) FROM foo GROUP BY lowcase;
*** BOOM ***
--Also when not in target list
SELECT count(b) FROM foo GROUP BY lower(a);
*** BOOM AGAIN ***
least, Solaris 2.5.1. We use it in backend/utils/adt/int8.c.
Add a check to configure so that we see if it exists or not, and, if not,
compile in snprintf.c from backend/port, which was taken from, and falls under
the same Berkeley license as us, the FreeBSD libc/stdio ...
As Bruce mentioned, this is due to the conflict among changes we made.
Included patches should fix the problem(I changed all MB to
MULTIBYTE). Please let me know if you have further problem.
P.S. I did not include pathces to configure and gram.c to save the
file size(configure.in and gram.y modified).
From: t-ishii@sra.co.jp
Attached are patches to enhance the multi-byte support. (patches are
against 7/18 snapshot)
* determine encoding at initdb/createdb rather than compile time
Now initdb/createdb has an option to specify the encoding. Also, I
modified the syntax of CREATE DATABASE to accept encoding option. See
README.mb for more details.
For this purpose I have added new column "encoding" to pg_database.
Also pg_attribute and pg_class are changed to catch up the
modification to pg_database. Actually I haved added pg_database_mb.h,
pg_attribute_mb.h and pg_class_mb.h. These are used only when MB is
enabled. The reason having separate files is I couldn't find a way to
use ifdef or whatever in those files. I have to admit it looks
ugly. No way.
* support for PGCLIENTENCODING when issuing COPY command
commands/copy.c modified.
* support for SQL92 syntax "SET NAMES"
See gram.y.
* support for LATIN2-5
* add UNICODE regression test case
* new test suite for MB
New directory test/mb added.
* clean up source files
Basic idea is to have MB's own subdirectory for easier maintenance.
These are include/mb and backend/utils/mb.
calls. Outside a transaction, the backend detects them as buffer
leaks; it sends a NOTICE, and frees them. This sometimes cause a
segmentation fault (at least on Linux). These indexes are initialized
on the first lo_read/lo_write/lo_tell call, and (normally) closed
on a lo_close call. Thus the buffer leaks appear when lo direct
access functions are used, and not with lo_import/lo_export functions
(libpq version calls lo_close before ending the command, and the
backend version uses another path).
The included patches (against recent snapshot, and against 6.3.2)
cause indexes to be closed on transaction end (that is on explicit
'END' statment, or on command termination outside trasaction blocks),
thus preventing the buffer leaks while increasing performance inside
transactions. Some (all?) 'classic' memory leaks are also removed.
I hope it will be ok.
--- Pascal ANDRE, graduated from Ecole Centrale Paris andre@via.ecp.fr
now. Here some tested features, (examples included in the patch):
1.1) Subselects in the having clause 1.2) Double nested subselects
1.3) Subselects used in the where clause and in the having clause
simultaneously 1.4) Union Selects using having 1.5) Indexes
on the base relations are used correctly 1.6) Unallowed Queries
are prevented (e.g. qualifications in the
having clause that belong to the where clause) 1.7) Insert
into as select
2) Queries using the having clause on view relations also work
but there are some restrictions:
2.1) Create View as Select ... Having ...; using base tables in
the select 2.1.1) The Query rewrite system:
2.1.2) Why are only simple queries allowed against a view from 2.1)
? 2.2) Select ... from testview1, testview2, ... having...; 3) Bug
in ExecMergeJoin ??
Regards Stefan
in a more readable form. -- I am submitting the following patches
to the June 6, 1998 snapshot of PostgreSQL. These patches implement
a port of PostgreSQL to SCO UnixWare 7, and updates the Univel port
(UnixWare 2.x). The patched files, and the reason
for the patch are:
File Reason for the patch ---------------
---------------------------------------------------------------
src/backend/port/dynloader/unixware.c src/backend/port/dynloader/unixware.h
src/include/port/unixware.h src/makefiles/Makefile.unixware
src/template/unixware
Created for the UNIXWARE port.
src/include/port/univel.h
Modifed this file to work with the changes made to
s_lock.[ch].
src/backend/storage/buffer/s_lock.c src/include/storage/s_lock.h
Moved the UNIXWARE (and Univel) tas() function from
s_lock.c to s_lock.h. The UnixWare compiler asm
construct is treated as a macro and needs to be in
the s_lock.h file. I also reworked the tas()
function to correct some errors in the code.
src/include/version.h.in
The use of the ## operator with quoted strings in
the VERSION macro caused problems with the UnixWare
C compiler. I removed the ## operators since they
were not needed in this case. The macro expands
into a sequence of quoted strings that will be
concatenated by any ANSI C compiler.
src/config.guess
This script was modified to recognize SCO UnixWare
7.
src/configure src/configure.in
The configure script was modified to recognize SCO
UnixWare 7.
Billy G. Allie
NS32K machine I contributed. In any case, I now have postgresql-6.3
running again on NetBSD/pc532, a NS32532 machine. The following
changes are needed relative to the src directory. (It looks like
support was partially removed when the files were moved from the
src/backend/storage/.... tree to the src/include tree.)
If you need me to get a current development version of postgresql
for this change let me know. Also, let me know if this code needs
updating due to another code movement that deleted the old NS32K
support.
Thank you.
Phil Nelson
GCC, the inner "#if defined(__GNUC__)" can just be omitted in that
architecture's block.
The existing arrangement with an outer "#if defined(__GNUC__)"
doesn't have any obvious benefit, and it encourages missed cases
like this one.
BTW, I'd suggest making the definition of clear_lock for HPUX be
static const slock_t clear_lock = {{-1, -1, -1, -1}};
The extra braces are needed to suppress warnings from gcc, and
declaring it const just seems like good practice.
regards, tom lane
but as I don't have access to a sparc for testing I just did what
I could. I am guessing here, but please apply the following to your
pgsql and let me know what happens. Also, cd to src/storage/buffer
and do 'make s_lock_test' as well.
David Gould
Making PQrequestCancel safe to call in a signal handler turned out to be
much easier than I feared. So here are the diffs.
Some notes:
* I modified the postmaster's packet "iodone" callback interface to allow
the callback routine to return a continue-or-drop-connection return
code; this was necessary to allow the connection to be closed after
receiving a Cancel, rather than proceeding to launch a new backend...
Being a neatnik, I also made the iodone proc have a typechecked
parameter list.
* I deleted all code I could find that had to do with OOB.
* I made some edits to ensure that all signals mentioned in the code
are referred to symbolically not by numbers ("SIGUSR2" not "2").
I think Bruce may have already done at least some of the same edits;
I hope that merging these patches is not too painful.
Through some minor changes, I have been able to compile the libpq
client libraries on the Win32 platform. Since the libpq communications
part has been rewritten, this has become much easier. Enclosed is
a patch that will allow at least Microsoft Visual C++ to compile
libpq into both a static and a dynamic library. I will take a look
at porting the psql frontend as well, but I figured it was a good
idea to send in these patches first - so no major changes are done
to the files before it gets applied (if it does).
Regards,
Magnus Hagander