not TRUE. Otherwise we break pl call handler functions. fmgr_oldstyle
will take care of making sure the semantics are the same for C functions.
Clean up some slightly grotty coding in 7.0 pg_class reading, also.
when we need to move to a new page; as long as we can insert the new
tuple on the same page as before, we only need LockBuffer and not the
expensive stuff. Also, twiddle bufmgr interfaces to avoid redundant
lseeks in RelationGetBufferForTuple and BufferAlloc. Successive inserts
now require one lseek per page added, rather than one per tuple with
several additional ones at each page boundary as happened before.
Lock contention when multiple backends are inserting in same table
is also greatly reduced.
- Fix view dumping SQL for V7.0
- Fix bug when getting view oid with long view names
- Treat SEQUENCE SET TOC entries as data entries rather than schema
entries.
- Make allowance for data entries that did not have a data dumper
routine (eg. SEQUENCE SET)
not being consulted anywhere, so remove it and remove the _mdnblocks()
calls that were used to set it. Change smgrextend interface to pass in
the target block number (ie, current file length) --- the caller always
knows this already, having already done smgrnblocks(), so it's silly to
do it over again inside mdextend. Net result: extension of a file now
takes one lseek(SEEK_END) and a write(), not three lseeks and a write.
a PostgreSQL user-defined function. The Metaphone system is a method of
matching similar sounding names (or any words) to the same code.
Metaphone was invented by Lawrence Philips as an improvement to the popular
name-hashing routine, Soundex.
This metaphone code is from Michael Kuhn, and is detailed at
http://aspell.sourceforge.net/metaphone/metaphone-kuhn.txt
Joel Burton
constraint names.
> > A reasonable interpretation of DROP CONSTRAINT "foo" is to drop *all*
> > constraints named "foo" on the target table.
>
> Then it should probably be a good thing to avoid the automatic
> generation of
> duplicate names? I might take a look at that, actually...
>
Christopher Kings-Lynne
jdbc/Connection.java
Andy
P.S. in Connection.java if encoding=="WIN" then dbEncoding is set to
"Cp1252".
What if it's Cyrillic "WIN"? Than it should be "Cp1251". Is there any
way to fix that without making different "WIN" encodings in
PostgreSQL?
Andy Rysin
in referencing and referenced columns of an fk constraint
aren't comparable using '=' at constraint definition time
rather than insert/update time.
Stephan Szabo
enables pltcl unknown support.
Also it adds substituting of tclsh with tclsh that was by configure in
pltcl_*mod scripts. For example, On freebsd, tclsh can be called
tclsh8.2 or
tclsh8.3 depending on installed version of Tcl.
After patching files
src/pl/tcl/modules/pltcl_listmod
src/pl/tcl/modules/pltcl_loadmod
src/pl/tcl/modules/pltcl_delmod
must be renamed(copied,repocopied) to
src/pl/tcl/modules/pltcl_listmod.in
src/pl/tcl/modules/pltcl_loadmod.in
src/pl/tcl/modules/pltcl_delmod.in
seva@sevasoft.kiev.ua
still looking at the best way to integrate Tom Vijlbrief's fixes
(insofar as they're still needed); would 7.2 be a suitable time for
incompatible API changes?
Jeroen
Changes:
(*) Introduced bool, true, false (replacing some int, 1, 0)
(*) Made some member functions const
(*) Documented GetIsNull()
(*) Marked DisplayTuples() and PrintTuples() as obsolescent; fixed possible
portability problem (assumed that NULL pointer equals all-zero bit pattern)
(*) PrintTuples(): renamed width parameter to fillAlign to conform with other
usage; fixed memory leak and compile issue w.r.t. field separator (should
also slightly improve performance)
(*) Fixed some minor compilation issues
(*) Moved "using namespace std;" out of headers, where they didn't belong; used
new (temporary) preprocessor macro PGSTD to do this
(*) Made ToString() static, removed unneeded memset(), made buffer size adapt
to sizeof(int)
(*) Made some constructors explicit
(*) Changed some const std::string & parameters to plain std::string
(*) Marked PgCursor::Cursor(std::string) as obsolescent (setter with same name
as getter--bad style)
(*) Renamed some paramaters previously named "string"
(*) Introduced size_type typedef for number of tuples in result set
(*) PgTransaction now supports re-opening after closing, and aborts if not
explicitly committed prior to destruction
J. T. Vermeulen
collected by ANALYZE. Also, add some modest amount of intelligence to
guesses that are used for varlena columns in the absence of any ANALYZE
statistics. The 'width' reported by EXPLAIN is finally something less
than totally bogus for varlena columns ... and, in consequence, hashjoin
estimating should be a little better ...
to their children, leading to misbehavior if they had any children that paid
attention to chgParam (most plan node types don't). Append's bug has been
there a long time, but nobody had noticed because it used to be difficult
to create a query where an Append would be used below the top level of a
plan; so there were never any parameters getting passed down. SubqueryScan
is new in 7.1 ... and I'd modeled its behavior on Append :-(
> cronjob:
> NOTICE: RegisterSharedInvalid: SI buffer overflow
> NOTICE: InvalidateSharedInvalid: cache state reset
> I don't understand what these mean. Should I be concerned about them
> and what do they signify?
No real need to worry. Those should've been downgraded to DEBUG-level
messages a release or two back, but nobody bothered...
Tom Lane
a separate statement (though it can still be invoked as part of VACUUM, too).
pg_statistic redesigned to be more flexible about what statistics are
stored. ANALYZE now collects a list of several of the most common values,
not just one, plus a histogram (not just the min and max values). Random
sampling is used to make the process reasonably fast even on very large
tables. The number of values and histogram bins collected is now
user-settable via an ALTER TABLE command.
There is more still to do; the new stats are not being used everywhere
they could be in the planner. But the remaining changes for this project
should be localized, and the behavior is already better than before.
A not-very-related change is that sorting now makes use of btree comparison
routines if it can find one, rather than invoking '<' twice.
routine DetermineLocalTimeZone(). In that routine, be more wary of
broken mktime() implementations than the original code was: don't allow
mktime to change the already-set y/m/d/h/m/s information, and don't
use tm_gmtoff if mktime failed. Possibly this will resolve some of
the complaints we've been hearing from users of Middle Eastern timezones
on RedHat.
give consistent results for all datatypes. Types float4, float8, and
numeric were broken for NaN values; abstime, timestamp, and interval
were broken for INVALID values; timetz was just plain broken (some
possible pairs of values were neither < nor = nor >). Also clean up
text, bpchar, varchar, and bit/varbit to eliminate duplicate code and
thereby reduce the probability of similar inconsistencies arising in
the future.
This is an extension to the SQL9x standard, but is consistant with usage
of the underlying date_part() function used to implement it.
Example: EXTRACT('YEAR',...)
No impact on regression tests.
join. This is needed to avoid improper evaluation of expressions that
should be nulled out, as in Victor Wagner's bug report of 4/27/01.
Pretty ugly solution, but no time to do anything better for 7.1.1.
1) [ODBC] Psqlodbc and Centura: here it is a patch
posted by Matteo Cavalleli
2) [ODBC] pgsqODBC binding parameters II
posted by Ludek Finstrle
3) Invalid Page Fault in PSQLODBC.DLL
personal mail from Johann Zuschlag
Hiroki Kataoka kataoka@interwiz.koganei.tokyo.jp
function arguments in join queries: copy the tuples into
TransactionCommandContext so they don't get recycled too soon. This is
horrid, but not any worse than 7.0 or before, which also leaked such
tuples until end of query. A proper fix will require allowing tuple
datums to be physically stored inside larger tuple datums, which opens
up a bunch of issues that can't realistically be solved for 7.1.1.
functions of join or subselect aliases. It'd be awfully nice if this
code knew for sure whether it was dealing with 'x.f' or 'f(x)' syntax;
maybe we can fix that in a future cycle.
or view that's been dropped and then recreated with the same name (but,
perhaps, different columns). Eventually we'd like to support this but
for now all we can do is fail cleanly, rather than possibly coredumping
if we proceed using the obsolete rule.
to specific base or join RelOptInfo nodes during planning. This preserves
the more-intuitive behavior of 7.0.* --- if you write an expensive clause
(such as a sub-select) last, it should get evaluated last. Someday we
ought to try to have some intelligence about the order of evaluation of
WHERE clauses, but for now we should not override what the user wrote.
only possible failure is in pq_flush, which will log a (better!) report
anyway --- so pq_endmessage is just cluttering the log with a redundant
entry. This matters when a client crashes partway through a large query,
since we will emit many broken-pipe reports before finishing the query
and exiting.
lists should be reverse-compiled into targetlist index numbers, because
that's the only interpretation the parser allows for a constant in these
clauses. (Ergo, the only way they could have gotten into the list in
the first place is to have come from the targetlist; so this should always
work.) Per problem report from Peter E.
join clauses. The mergejoin executor wants all the join clauses to appear
as merge quals, not as extra joinquals, for these kinds of joins. But the
planner would consider plans in which partially-sorted input paths were
used, leading to only some of the join clauses becoming merge quals.
This is fine for inner/left joins, not fine for right/full joins.
Although it was now using the right equation, it was making bogus choices
of the precision to compute intermediate results to. I'm not sure this
is really right even yet, but it's better than before ...
(which failed miserably during DST) to just compare against a time
derived from a timestamp value.
Certainly not a direct check for a correct result, but should work
at any time of year.
it needs to ensure that data structures attached to fmgr info records in
the trees will stick around that long, too. Current code was crashing
on cases like datatypes with old-style I/O functions.
VFD entries. On platforms where dereferencing a null pointer doesn't
lead to coredump, it's possible that this omission could have led to
unpleasant behavior like deleting the wrong file.
physical file has disappeared. There is no really good reason why
relcache should be opening the underlying file at all, AFAICS.
In any case we needn't raise a hard error here.
with different default values, unless the child table redeclares the
column with an explicit default. This was judged to be the approach
least likely to cause unpleasant surprises.
the UDT/function order problem.
- Rudimentary support for dependencies in archives.
Uses dependencies to modify the OID used in sorting TOC
entries. This will NOT handle multi-level dependencies,
but will manage simple relationships like UDTs & their functions.
- Treat OIDs with more respect (avoid using ints, use macros
for conversion & comparison).
ready. It appears that most (all?) Unixen will consider a socket to
be read or write ready if it has an error condition, but of course
Microsoft does things differently.
in CREATE TABLE, but give a warning notice. Clean up inconsistent
handling of defaults and NOT NULL flags from multiply-inherited columns.
Per pghackers discussion 28-Mar through 30-Mar.
as six bytes not eight. This fixes a regression test failure but more
importantly avoids wasting four bytes of pad space in every tuple header.
Also add some commentary about what's going on.
inheritance query: make duplicate copies of subplans in adjust_inherited_attrs.
When we redesign querytrees we really gotta do something about this
issue of whether querytrees are read-only and can share substructure
or not.
more recent versions of the IBM C++ compiler (now called VisualAge C++).
The C++ part was previously broken (g++ and xlC), thus this is zero risk.
Only AIX specific parts are touched (1 Makefile.shlib line (link with $(COMPILER
) instead
of $(CC) and one shell script line (parameter -C to nm to not demangle C++ symbo
ls for
.exp file)).
I thus ask you to please apply this patch before release.
With or without this patch RC1 on AIX 4.3.2 RS6000 passes "gmake check" for both
the native
compiler vac.C 5.0.1 and gcc 2.95.2 :-)
Andreas
I posted this to the list a few days ago, but it was not addressed. Can
someone please make the changes to the src/test/regress/resultmap?
Thanks.
- brandon
accepts nnnLL syntax for long long constants. If so, decorate the CRC64
constants with LL to avoid warnings and/or erroneous results from certain
non-standards-compliant compilers.
on Alpha (because parser mistakenly assumes that a nonoverflow result
from strtol means the value will fit into int4). A scan for other uses
of strtol and strtoul found a couple other places with the same mistake;
fix them too. The changes are all conditional on HAVE_LONG_INT_64 to
avoid complaints from compilers that think x != x is a silly test
(cf. pg_atoi).
*before* acquiring shlock on buffer context. This way we should be
protected against conflicts with FlushRelationBuffers.
(Seems we never do excl lock and then StartBufferIO for the same
buffer, so there should be no deadlock here, - but we'd better
check this very soon).
- Avoid forcing table name to lower case in FixupBlobXrefs
- Removed fmtId calls for all ArchiveEntry name fields. This fixes
quoting problems in trigger enable/disable code for mixed case
table names, and avoids commands like 'pg_restore -t '"TblA"'
O_SYNC, or O_DSYNC (as available on a given platform). Add GUC parameter
to control sync method.
Also, add defense to XLogWrite to prevent it from going nuts if passed
a target write position that's past the end of the buffers so far filled
by XLogInsert.
Provide an extenisible scheme of encoding conversion.
As the first step, SJIS and BIG5 are supported.
From now on multibyte people would be happy to use
this psqlodbc driver.
Eiji Tokuya e-tokuya@mail.sankyo-unyu.co.jp
I'm not sure that it's really necessary to save insert events when there
are only after update or delete triggers, but certainly it's wrong for
COPY to behave differently from an INSERT query.
detect case that next page in log came from an older run than the prior
page. This avoids the necessity to re-zero the log after recovery from
a crash, which is good because we need not risk destroying valuable log
information.
This forces another initdb since yesterday :-(. Need to get that log
reset utility done...
ODBC driver on Windows 9X/ME/NT/2K when using the later versions of the
driver that don't have the Installshield installation:
1) Install psqlodbc.dll in to C:\Windows\System or C:\Winnt\System32
2) Add the registry settings in the attached file using regedit.
A useful addition to src/interfaces/odbc perhaps?
Regards, Dave.
* Store two past checkpoint locations, not just one, in pg_control.
On startup, we fall back to the older checkpoint if the newer one
is unreadable. Also, a physical copy of the newest checkpoint record
is kept in pg_control for possible use in disaster recovery (ie,
complete loss of pg_xlog). Also add a version number for pg_control
itself. Remove archdir from pg_control; it ought to be a GUC
parameter, not a special case (not that it's implemented yet anyway).
* Suppress successive checkpoint records when nothing has been entered
in the WAL log since the last one. This is not so much to avoid I/O
as to make it actually useful to keep track of the last two
checkpoints. If the things are right next to each other then there's
not a lot of redundancy gained...
* Change CRC scheme to a true 64-bit CRC, not a pair of 32-bit CRCs
on alternate bytes. Polynomial borrowed from ECMA DLT1 standard.
* Fix XLOG record length handling so that it will work at BLCKSZ = 32k.
* Change XID allocation to work more like OID allocation. (This is of
dubious necessity, but I think it's a good idea anyway.)
* Fix a number of minor bugs, such as off-by-one logic for XLOG file
wraparound at the 4 gig mark.
* Add documentation and clean up some coding infelicities; move file
format declarations out to include files where planned contrib
utilities can get at them.
* Checkpoint will now occur every CHECKPOINT_SEGMENTS log segments or
every CHECKPOINT_TIMEOUT seconds, whichever comes first. It is also
possible to force a checkpoint by sending SIGUSR1 to the postmaster
(undocumented feature...)
* Defend against kill -9 postmaster by storing shmem block's key and ID
in postmaster.pid lockfile, and checking at startup to ensure that no
processes are still connected to old shmem block (if it still exists).
* Switch backends to accept SIGQUIT rather than SIGUSR1 for emergency
stop, for symmetry with postmaster and xlog utilities. Clean up signal
handling in bootstrap.c so that xlog utilities launched by postmaster
will react to signals better.
* Standalone bootstrap now grabs lockfile in target directory, as added
insurance against running it in parallel with live postmaster.
tuples inserted/deleted/updated in a single transaction. On my machine,
this reduced the time to delete 80000 tuples in a foreign-key-referencing
table from ~15min to ~8sec.
of a counted input string. Marinos Yannikos' recent crash report turns
out to be due to applying pg_ascii2wchar_with_len to a TEXT object that
is smack up against the end of memory. This is the second just-barely-
reproducible bug report I have seen that traces to some bit of code
fetching one more byte than it is allowed to. Let's be more careful
out there, boys and girls.
While at it, I changed the code to not risk a similar crash when there
is a truncated multibyte character at the end of an input string. The
output in this case might not be the most reasonable output possible;
if anyone wants to improve it further, step right up...
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
Tue Feb 13 16:33:00 GMT 2001 peter@retep.org.uk
- More TestCases implemented. Refined the test suite api's.
- Removed need for SimpleDateFormat in ResultSet.getDate() improving
performance.
- Rewrote ResultSet.getTime() so that it uses JDK api's better.
Tue Feb 13 10:25:00 GMT 2001 peter@retep.org.uk
- Added MiscTest to hold reported problems from users.
- Fixed PGMoney.
- JBuilder4/JDBCExplorer now works with Money fields. Patched Field &
ResultSet (lots of methods) for this one. Also changed cash/money to
return type DOUBLE not DECIMAL. This broke JBuilder as zero scale
BigDecimal's can't have decimal places!
- When a Statement is reused, the previous ResultSet is now closed.
- Removed deprecated call in ResultSet.getTime()
Thu Feb 08 18:53:00 GMT 2001 peter@retep.org.uk
- Changed a couple of settings in DatabaseMetaData where 7.1 now
supports those features
- Implemented the DatabaseMetaData TestCase.
Wed Feb 07 18:06:00 GMT 2001 peter@retep.org.uk
- Added comment to Connection.isClosed() explaining why we deviate from
the JDBC2 specification.
- Fixed bug where the Isolation Level is lost while in autocommit mode.
- Fixed bug where several calls to getTransactionIsolationLevel()
returned the first call's result.
as previously discussed.
It makes AIX and IRIX not use DST for dates before 1970.
The following expected files need to be removed from the regression tests,
they contain wrong results and are not needed any more.
src/test/regress/expected/horology-1947-PDT.out
src/test/regress/expected/tinterval-1947-PDT.out
src/test/regress/expected/abstime-1947-PDT.out
Zeugswetter Andreas
- Add extra arg to formatStringLiteral to specify how to handle LF & TAB.
I opted for encoding them except in procedure bodies & comments
- Fixed bug in tar file input when restoring blobs
definitions from K&R to ANSI C style, and fix broken assumption that
int and long are the same datatype. This repairs problems observed
on Alpha with regexps having between 32 and 63 states.
two transactions create the same table name concurrently, the one that
fails will complain about unique index pg_class_relname_index, rather than
about pg_type_typname_index which'll confuse most people. Free side
benefit: pg_class.reltype is correctly linked to the pg_type entry now.
It's been zero in all but the preloaded pg_class entries since who knows
when.
1) Tidies up the Datasource Dialogue now the version options are gone.
2) Tidies a comment in info.c.
3) Increments all version numbers to 07.01.0003 to take account of recent
revisions.
Regards, Dave Page
are now separate files "postgres.h" and "postgres_fe.h", which are meant
to be the primary include files for backend .c files and frontend .c files
respectively. By default, only include files meant for frontend use are
installed into the installation include directory. There is a new make
target 'make install-all-headers' that adds the whole content of the
src/include tree to the installed fileset, for use by people who want to
develop server-side code without keeping the complete source tree on hand.
Cleaned up a whole lot of crufty and inconsistent header inclusions.
rather than executing the INTO clause with non-plpgsql semantics
as it was doing for the last few weeks/months. This keeps our options
open for making it do the right plpgsql-ish thing in future without
creating a backwards compatibility problem. There is no loss of
functionality since people can get the same behavior with CREATE TABLE AS.
Add -l option to name log file. Set umask to 077.
Proper file descriptor redirection to allow postmaster to detach from
shell's process group.
Add -s option to turn off informational messages.
any other client connections that may exist (which would only happen if
another client is currently in the authentication cycle). This avoids
wastage of open descriptors in a child. It might also explain peculiar
behaviors like not closing connections when expected, since the kernel
will probably not signal EOF as long as some other backend is randomly
holding open a reference to the connection, even if the client went away
long since ...
The driver version is 07.01.0002 now.
1) initialized pg_version by DSN's protocol info
so that we could always use pg_version info
once a connection is established (pg_version()
didn't exist before 6.4). PROTOCOL_XX() macros
are removed(except from connection.[ch]).
2) provided a few macros to encapsulate connection's
version info and replaced existent comparison
stuff by those macros.
3) change SQLTables() so that 7.1 servers could show
views.
In addtion, the following patch from Dave Page is applied.
This patch fixes a bug in SQLGetInfo for SQL_DBMS_VER which corrupted the
driver version string. The driver version number has also been incremented
to 07.01.0002.
Regards, Dave. <<odbc.diff>>
elog(ERROR) not an Assert trap, since we've downgraded out-of-memory to
elog(ERROR) not a fatal error. Also, change the hard boundary from 256Mb
to 1Gb, just so that anyone who's actually got that much memory to spare
can play with TOAST objects approaching a gigabyte.
- Some minor additions to Statement to make our own extensions more
portable.
- Statement.close() will now call ResultSet.close() rather than just
dissasociating with it.
- Fixed bug where Statement.setMaxRows() was a global setting. Now
limited to just itself.
- Changed LargeObject.read(byte[],int,int) to return the actual number
of bytes read (used to be void).
- LargeObject now supports InputStream's!
- PreparedStatement.setBinaryStream() now works!
- ResultSet.getBinaryStream() now returns an InputStream that doesn't
copy the blob into memory first!
- Connection.isClosed() now tests to see if the connection is still alive
rather than if it thinks it's alive.
allocated by plan nodes are not leaked at end of query. This doesn't
really matter for normal queries, but it sure does for queries invoked
repetitively inside SQL functions. Clean up some other grotty code
associated with tupdescs, and fix a few other memory leaks exposed by
tests with simple SQL functions.
Ok. I have made patches for fixing some of pg_dump problems(see
attached patches). The patches address the problem with user defined
functions, operators and aggregates.
and two 'win32.mak'. Addresses the following:
1) Oops. Spelled fcntl.h wrong in the last one. D'uh.
2) PG_VERSION changed to be defined with " around it. psql/command.c failed
to compile without that.
3) Changed makefiles to use "/MD" and link both psql and libpq.dll against
MSVCRT.DLL instead of a static library. This takes care of the
crash-upon-free in psql.
I *think* this is what is on the "Open 7.1 Items" list as "Magnus Hagander
ODBC Issues?". It has nothing to do with ODBC, but it's the only issue I've
been involved with...
Magnus Hagander
original table ('OLD' table) in its join tree if OLD is referenced by
either the rule action, the rule qual, or the original query qual that
will be added to the rule action. However, we only want one instance
of the original table to be included; so beware of the possibility that
the rule action already has a jointree entry for OLD.
regression tests for Pgsql 7.1beta3 pass. This is very similr to the one I
submitted back in July for Linux/Alpha. Apparently non-x86 Linux machines
like to compute nth place float point digits like Sun/Solaris does?
Otherwise, 7.1beta3 runs without problems (i.e. all other
regression tests pass) on my Sparc 20 running Debian GNU/Linux 2.2.
Ryan Kirkpatrick
rather than coredumping (as prior 7.1 code did) or silently dropping the
condition (as 7.0 did). This is annoying but there doesn't seem to be
any good way to fix it, short of a major querytree restructuring.
actually) to ensure that its file access time doesn't get old enough to
tempt a /tmp directory cleaner to remove it. Still another reason we
should never have put the sockets in /tmp in the first place ...
truncating to integer. Remove regress test that checks whether
4567890123456789 can be converted to float without loss; since that's
52 bits, it's on the hairy edge of failing with IEEE float8s, and indeed
rint seems to give platform-dependent results for it.
dialogue from '6.4/6.5' to '6.5+' and removes some C++ comments from
resource.h (which VC++ insists on putting there).
odbc2.diff adds code to query the PostgreSQL version upon connection. This
is then used to determine what values to return for from SQLGetInfo for
SQL_DBMS_VER, SQL_MAX_ROW_SIZE, SQL_MAX_STATEMENT_LEN, SQL_OJ_CAPABILITIES
and SQL_OUTER_JOINS. The version string as returned by SELECT vERSION() (as
a char array) and the major.minor version number (as a flost) have been
added to the ConnectionClass structure.
Dave Page
and new root page if old root one was splitted but new root page
wasn't created.
New code is protected by FixBTree bool flag setted to FALSE, so
nothing should be affected by this untested approach.
some more osteric bugs is easier. If only 1 arg is supplied and it's
of type Exception, then that Exception's stacktrace is now included.
This was done as there's been a report of an unusual bug during connection.
This will make this sort of bug hunting easier from now on.
problems with char array sizes having set a couple of constants to 0 for
unlimited query length and row length. This additional patch cleans those
problems up by defining a new constant (STD_STATEMENT_LEN) to 65536 and
using that in place of MAX_STATEMENT_LEN.
Another constant (MAX_MESSAGE_LEN) was defined as 2*BLCKSZ, but is now
65536. This is used to define the length of the message buffer in a number
of places and as I understand it (probably not that well!) therefore also
places a limit on the query length. Fixing this properly is beyond my
capabilities but 65536 should hopefully be large enough for most people.
Apologies for being over-enthusiastic and posting 3 patches in one day
rather than 1 better tested one!
Regards,
Dave Page
> Sent: 24 January 2001 16:51
> To: Dave Page
> Subject: Re: [PATCHES] ODBC Patch for OJs/Large Querys & Rows
>
>
> > SQL_OJ_LEFT = Left outer joins are supported.
>
> Yes.
<snip>
In addition to my earlier patch, this one adds support for SQLGetInfo
SQL_OJ_CAPABILITIES to the ODBC driver.
Dave Page
following but it does *not* check whether the user is connected to
PostgreSQL 7.0.x or 7.1 first (as would be required for some of the
features) - the driver doesn't do this at all afaik and it's beyond my
capabilities to implement such checking in code that doesn't look like it
was written by my 1 year old daughter!
1) The driver now reports no maximum query length (SQL_MAX_QUERY_SIZE).
2) The driver now reports no maximum row length (SQL_MAX_ROW_SIZE).
3) The driver now reports that Outer Joins are supported (SQL_OUTER_JOINS),
but still does not report oj capabilities (SQL_OJ_CAPABILITIES).
4) The version number has been incremented to 7.1.0000 in psqlodbc.h *and*
psqlodbc.rc
Regards,
Dave Page
objects that Thomas pointed out might be a problem.
PPS. I have included and updated the comments from the original patch
request to reflect the changes made in this revised patch.
> Attached is a set of patches for a couple of bugs dealing with
> timestamps in JDBC.
>
> Bug#1) Incorrect timestamp stored in DB if client timezone different
> than DB.
> The buggy implementation of setTimestamp() in PreparedStatement simply
> used the toString() method of the java.sql.Timestamp object to convert
> to a string to send to the database. The format of this is yyyy-MM-dd
> hh:mm:ss.SSS which doesn't include any timezone information. Therefore
> the DB assumes its timezone since none is specified. That is OK if the
> timezone of the client and server are the same, however if they are
> different the wrong timestamp is received by the server. For example if
> the client is running in timezone GMT and wants to send the timestamp
> for noon to a server running in PST (GMT-8 hours), then the server will
> receive 2000-01-12 12:00:00.0 and interprete it as 2000-01-12
> 12:00:00-08 which is 2000-01-12 04:00:00 in GMT. The fix is to send a
> format to the server that includes the timezone offset. For simplicity
> sake the fix uses a SimpleDateFormat object with its timezone set to GMT
> so that '+00' can be used as the timezone for postgresql. This is done
> as SimpleDateFormat doesn't support formating timezones in the way
> postgresql expects.
>
> Bug#2) Incorrect handling of partial seconds in getting timestamps from
> the DB
>
> When the SimpleDateFormat object parses a string with a format like
> yyyy-MM-dd hh:mm:ss.SS it expects the fractional seconds to be three
> decimal places (time precision in java is miliseconds = three decimal
> places). This seems like a bug in java to me, but it is unlikely to be
> fixed anytime soon, so the postgresql code needed modification to
> support the java behaviour. So for example a string of '2000-01-12
> 12:00:00.12-08' coming from the database was being converted to a
> timestamp object with a value of 2000-01-12 12:00:00.012GMT-08:00. The
> fix was to check for a '.' in the string and if one is found append on
> an extra zero to the fractional seconds part.
>
>
> I also did some cleanup in ResultSet.getTimestamp(). This method has
> had multiple patches applied some of which resulted in code that was no
> longer needed. For example the ISO timestamp format that postgresql
> uses specifies the timezone as an offset like '-08'. Code was added at
> one point to convert the postgresql format to the java one which is
> GMT-08:00, however the old code was left around which did nothing. So
> there was code that looked for yyyy-MM-dd hh:mm:sszzzzzzzzz and
> yyyy-MM-dd hh:mm:sszzz. This second format would never be encountered
> because zzz (i.e. -08) would be converted into the former (also note
> that the SimpleDateFormat object treats zzzzzzzzz and zzz the same, the
> number of z's does not matter).
>
>
> There was another problem/fix mentioned on the email lists today by
> mcannon@internet.com which is also fixed by this patch:
>
> Bug#3) Fractional seconds lost when getting timestamp from the DB
> A patch by Jan Thomea handled the case of yyyy-MM-dd hh:mm:sszzzzzzzzz
> but not the fractional seconds version yyyy-MM-dd hh:mm:ss.SSzzzzzzzzz.
> The code is fixed to handle this case as well.
Barry Lind
to the use of getpwuid when running in standalone mode.
this patch allocates some persistent storage (using
strdup) to store the username obtained with getpwuid
in src/backend/main/main.c. this is necessary because
later on, getpwuid is called again (in ValidateBinary).
the man pages for getpwuid on SCO OpenServer, FreeBSD,
and Darwin all have words to this effect (this is from
the SCO OpenServer man page):
Note
====
All information is contained in a static area, so it must
be copied if it is to be saved. Otherwise, it may be
overwritten on subsequent calls to these routines.
in particular, on my platform, the storage used to hold
the pw_name from the first call is overwritten such that
it looks like an empty username. this causes a problem
later on in SetSessionUserIdFromUserName.
i'd assume this isn't a problem on most platforms because
getpwuid is called with the same UID both times, and the
same thing ends up happening to that static storage each
time. however, that's not guaranteed, and is _not_ what
happens on my platform (at least :).
this is for the version of 7.1 available via anon cvs as
of Tue Jan 23 15:14:00 2001 PST:
.../src/backend/main/main.c,v 1.37 2000/12/31 18:04:35 tgl Exp
-michael thornburgh, zenomt@armory.com
and psql) again. Changes are:
1) psql requires the includes of "io.h" and "fcntl.h" in command.c in order
to make a call to open() work (io.h for _open(), fcntl.h for the O_xxx)
2) PG_VERSION is no longer defined in version.h[.in], but in configure.in.
Since we don't do configure on native win32, we need to put it in
config.h.win32 :-(
3) Added define of SYSCONFDIR to config.h.win32 - libpq won't compile
without it. This functionality is *NOT* tested - it's just defined as "" for
now. May work, may not.
4) DEF_PGPORT renamed to DEF_PGPORT_STR
I have done the "basic tests" on it - it connects to a database, and I can
run queries. Haven't tested any of the fancier functions (yet).
However, I stepped on a much bigger problem when fixing psql to work. It no
longer works when linked against the .DLL version of libpq (which the
Makefile does for it). I have left it linked against this version anyway,
pending the comments I get on this mail :-)
The problem is that there are strings being allocated from libpq.dll using
PQExpBuffers (for example, initPQExpBuffer() on line 92 of input.c). These
are being allocated using the malloc function used by libpq.dll. This
function *may* be different from the malloc function used by psql.exe - only
the resulting pointer must be valid. And with the default linking methods,
it *WILL* be different. Later, psql.exe tries to free() this string, at
which point it crashes because the free() function can't find the allocated
block (it's on the allocated blocks list used by the runtime lib of
libpq.dll).
Shouldn't the right thing to do be to have psql call termPQExpBuffer() on
the data instead? As it is now, gets_fromFile() will just return the pointer
received from the PQExpBuffer.data (this may well be present at several
places - this is the one I was bitten by so far). Isn't that kind of
"accessing the internals of the PQExpBuffer structure" wrong? Instead,
perhaps it shuold make a copy of the string, adn then termPQExpBuffer() it?
In that case, the string will have been allocated from within the same
library as the free() is called.
I can get it to work just fine by doing this - changing from (around line
100 of input.c):
and the same a bit further down in the same function.
But, as I said above, this may be at more places in the code? Perhaps
someone more familiar to it could comment on that?
What do you think shuld be done about this? Personally, I go by the "If you
allocate a piece of memory using an interface, use the same interface to
free it", but the question is how to make it work :-)
Also, AFAIK this only affects psql.exe, so the changes made to the libpq
this patch are required no matter how the other issue is handled.
Regards,
Magnus
