succeeds or not. Revise rtree page split algorithm to take care about
making a feasible split --- ie, will the incoming tuple actually fit?
Failure to make a feasible split, combined with failure to notice the
failure, account for Jim Stone's recent bug report. I suspect that
hash and gist indices may have the same type of bug, but at least now
we'll get error messages rather than silent failures if so. Also clean
up rtree code to use Datum rather than char* where appropriate.
One more :)) It's for improper function argumets for
PLTCL_UNKNOWN_SUPPORT code
I'm not an autoconf expert, but is it possible to enable unknown
support in pltcl with configure option ?
This support is really handy for real life usage of pl/tcl.
seva@sevasoft.kiev.ua
bits in JDBC & the first set of tools into contrib.
This is the third, and deals with enabling JDBC to be compiled with the main
source.
What it does is add a new option to configure: --with-java
This option tells configure to look for ant (our build tool of choice) and
if found, it then compiles both the JDBC driver and the new tools as part
of the normal make.
Also, when the postgresql install is done, all the .jar files are also
installed into the ${PGLIB}/java directory (thought best to keep then separate)
Now I had some conflicts when this applied so could someone please double check
that everything is ok?
Peter
am talking with Thomas Lockhart about the idea of bringing the PyGreSQL
version number into alignment with PostgreSQL so this may change to 7.1
before the release.
I have added to the copyright to indicate that from now on the PostgreSQL
copyright will apply. If someone wants to make that clearer please do.
The existing copyrights need to stay there for now but if necessary I can
ask Pascal Andre if he agrees to a different wording.
Added reference to the Python DB-API 2.0 compliant API wrapper.
Added reference to the PyGreSQL mailing list.
when user does another FETCH after reaching end of data, or another
FETCH backwards after reaching start. This is needed because some plan
nodes are not very robust about being called again after they've already
returned NULL; for example, MergeJoin will crash in some states but not
others. While the ideal approach would be for them all to handle this
correctly, it seems foolish to assume that no such bugs would creep in
again once cleaned up. Therefore, the most robust answer is to prevent
the situation from arising at all.
noncachable, so that CURRENT_DATE and CURRENT_TIME work as functions
again, rather than being collapsed to constants immediately. Marking the
reverse conversions noncachable might be overkill, but I'm not sure;
do these datatypes have the notion of a CURRENT value? Better safe than
sorry, for now.
vacuum analyze on pg_type fails if bogus entries remain in pg_operator.
Here is a sample script to reproduce the problem.
drop table t1;
create table t1(i int);
drop function foo(t1,t1);
create function foo(t1,t1) returns bool as 'select true' language 'sql';
create operator = (
leftarg = t1,
rightarg = t1,
commutator = =,
procedure = foo
);
drop table t1;
vacuum analyze;
Subject: [HACKERS] pgaccess Japanese input capability patch
From: Tatsuo Ishii <t-ishii@sra.co.jp>
To: teo@flex.ro
Cc: pgsql-hackers@postgresql.org, pgsql-interfaces@postgresql.org
Date: Sat, 24 Feb 2001 21:41:14 +0900
Hi Teodorescu,
I have made patches which enable pgaccess to input Japanese characters
in the table editing window. As you might know, to input Japanese
characters, we first type in "hiragana" then convert it to "kanji". To
make this proccess transparent to tcl application programs, libraries
are provided with localized version of Tcl/Tk. The patches bind
certain keys to initiate a function (kanjiInput) that is responsible
for the conversion process. If the function is not available, those
keys will not be binded.
Comments?
--
Tatsuo Ishii
only if at least N other backends currently have open transactions. This
is not a great deal of intelligence about whether a delay might be
profitable ... but it beats no intelligence at all. Note that the default
COMMIT_DELAY is still zero --- this new code does nothing unless that
setting is changed.
Also, mark ENABLEFSYNC as a system-wide setting. It's no longer safe to
allow that to be set per-backend, since we may be relying on some other
backend's fsync to have synced the WAL log.
does not lead to a one-second delay, but to an immediate EINVAL failure.
This causes CHECKPOINT to crash with s_lock_stuck much too quickly :-(.
Fix by breaking down the requested wait div/mod 1e6.
> Is there one LOCKMETHODCTL for every backend? I thought there was only
> one of them.
>>
>> You're right, that line is erroneous; it should read
>>
>> size += MAX_LOCK_METHODS * MAXALIGN(sizeof(LOCKMETHODCTL));
>>
>> Not a significant error but it should be changed for clarity ...
if it's correct to post here.
It's simple to do the translation, And I've test in 7.0.2 & current CVS,
seems pretty good.
If anyone want this little thing, I'll very happy.
use it is very simple, just gunzip it and copy to
$PGDIR/share/pgaccess/lib/languages/ for current CVS version,
and $PGDIR/pgaccess/lib/languages/ for 7.0*
BTW: I havn't got the tools to translate it to BIG5 encoding, is there
anybody to to it?
He Weiping(Laser Henry)
in Turkish locale. Keywords are now checked under pure ASCII case-folding
rules ('A'-'Z'->'a'-'z' and nothing else). However, once a word is
determined not to be a keyword, it will be case-folded under the current
locale, same as before. See pghackers discussion 20-Feb-01.
be lurking in the install target directory. But don't zap up-to-date
headers (so install-all-headers before regular install will work).
Per suggestion from Larry Rosenman.
use the ANSI varargs style (<stdarg.h>) not the old style. Tatsuo had
reported this change was necessary back in the 7.0 beta cycle (4/13/00)
but for some reason, making the edit never got done.
option of CREATE DATABASE. In pg_regress, create regression database
from template0 to ensure that any installation-local cruft in template1
will not mess up the tests.
waste of cycles on single-CPU machines, and of dubious utility on multi-CPU
machines too.
Tweak s_lock_stuck so that caller can specify timeout interval, and
increase interval before declaring stuck spinlock for buffer locks and XLOG
locks.
On systems that have fdatasync(), use that rather than fsync() to sync WAL
log writes. Ensure that WAL file is entirely allocated during XLogFileInit.
either wrong or unnecessary in most cases, and on systems where setting
status takes a kernel call, the overhead of setting status three times
per command rather than two is annoying.
Fri Feb 17 15:11:00 GMT 2001 peter@retep.org.uk
- Reduced the object overhead in PreparedStatement by reusing the same
StringBuffer object throughout. Similarly SimpleDateStamp's are alse
reused in a thread save manner.
- Implemented in PreparedStatement: setNull(), setDate/Time/Timestamp
using Calendar, setBlob(), setCharacterStream()
- Clob's are now implemented in ResultSet & PreparedStatement!
- Implemented a lot of DatabaseMetaData & ResultSetMetaData methods.
We have about 18 unimplemented methods left in JDBC2 at the current
time.
if the return datatype's input converter was at all strict, because the
converter would get called on junk data when returning NULL. Also
ensure that it gives an error rather than coredumping if someone tries
to use it in a trigger function.
1. If there is exactly one pg_operator entry of the right name and oprkind,
oper() and related routines would return that entry whether its input type
had anything to do with the request or not. This is just premature
optimization: we shouldn't return the single candidate until after we verify
that it really is a valid candidate, ie, is at least coercion-compatible
with the given types.
2. oper() and related routines only promise a coercion-compatible result.
Unfortunately, there were quite a few callers that assumed the returned
operator is binary-compatible with the given datatype; they would proceed
to call it without making any datatype coercions. These callers include
sorting, grouping, aggregation, and VACUUM ANALYZE. In general I think
it is appropriate for these callers to require an exact or binary-compatible
match, so I've added a new routine compatible_oper() that only succeeds if
it can find an operator that doesn't require any run-time conversions.
Callers now call oper() or compatible_oper() depending on whether they are
prepared to deal with type conversion or not.
The upshot of these bugs is revealed by the following silliness in PL/Tcl's
selftest: it creates an operator @< on int4, and then tries to use it to
sort a char(N) column. The system would let it do that :-( (and evidently
has done so since 6.3 :-( :-(). The result in this case was just a silly
sort order, but the reverse combination would've provoked coredump from
trying to dereference integers. With this fix you get more reasonable
behavior:
pltcl_test=# select * from T_pkey1 order by key1, key2 using @<;
ERROR: Unable to identify an operator '@<' for types 'bpchar' and 'bpchar'
You will have to retype this query using an explicit cast
automatically to compensate the lack of automatic
conversion functionality of PostgreSQL server.
For example if there's a numeric type binding
1.2567 --> 1.2567::numeric.
I hope this change would enable the use of numeric
type in MS-Access etc.
Thanks Hiroki Kataoka for his checking my code.
compressed storage works perfectly well. Might as well have a coherent
strategy for applying it, rather than the haphazard store-what-you-get
approach that was in the code before. The strategy I've set up here is
to attempt compression of any compressible index value exceeding
BLCKSZ/16, or about 500 bytes by default.
the old ones were not small enough to ensure r-tree and gist indexes would
get picked when available. These numbers are totally bogus anyway, but
in the absence of any real estimation technique, we'd like to select
indexes when available ...
per recent discussion in pgsql-odbc. Now SELECT is
a boundary but VACUUM isn't.
2) Put back the error handling behavior. When elog(ERROR)
was detected the driver automatically issue "ABORT"
if a transaction is in progress.
3) Driver version is 7.01.0003(Dave already set it but
it was put back).
such as
SELECT f1 FROM foo UNION SELECT ... ORDER BY upper(f1)
to draw
'ORDER BY on a UNION/INTERSECT/EXCEPT result must be on one of the result columns'
rather than the uninformative 'f1 not found' we were producing before.
Eventually this should actually work, but that looks much too hard to try
to implement in late beta...
clause with an alias is a <subquery> and therefore hides table references
appearing within it, according to the spec. This is the same as the
preliminary patch I posted to pgsql-patches yesterday, plus some really
grotty code in ruleutils.c to reverse-list a query tree with the correct
alias name depending on context. I'd rather not have done that, but unless
we want to force another initdb for 7.1, there's no other way for now.
- Fixed bug in LargeObject & BlobOutputStream where the stream's output
was not flushed when either the stream or the blob were closed.
- Fixed PreparedStatement.setBinaryStream() where it ignored the length
Tom Lane
Bruce Momjian
Peter Eisentraut
Peter Mount
Philip Warner
D'Arcy J.M. Cain
Tatsuo Ishii
Michael Meskes
Hiroshi Inoue
Vadim B. Mikheev