advertised in RowDescription message. Depending on the physical tuple's
column count is not really correct, since according to heap_getattr()
conventions the tuple may be short some columns, which will automatically
get read as nulls. Problem has been latent since forever, but was only
exposed by recent change to skip a projection step in SELECT * FROM...
blanks, in hopes of reducing the surprise factor for newbies. Remove
redundant operators for VARCHAR (it depends wholly on TEXT operations now).
Clean up resolution of ambiguous operators/functions to avoid surprising
choices for domains: domains are treated as equivalent to their base types
and binary-coercibility is no longer considered a preference item when
choosing among multiple operators/functions. IsBinaryCoercible now correctly
reflects the notion that you need *only* relabel the type to get from type
A to type B: that is, a domain is binary-coercible to its base type, but
not vice versa. Various marginal cleanup, including merging the essentially
duplicate resolution code in parse_func.c and parse_oper.c. Improve opr_sanity
regression test to understand about binary compatibility (using pg_cast),
and fix a couple of small errors in the catalogs revealed thereby.
Restructure "special operator" handling to fetch operators via index opclasses
rather than hardwiring assumptions about names (cleans up the pattern_ops
stuff a little).
single-byte encodings, and a direct C implementation of the single-argument
forms (where spaces are always what gets trimmed). This is in preparation
for using rtrim1() as the bpchar-to-text cast operator, but is a useful
performance improvement even if we decide not to do that.
independently of whether the struct tm tm_zone member exists.
Also run autoheader, which seems not to have been done lately;
it added about three more things to pg_config.h.in than I was expecting...
example from Rao Kumar. This is a very corner corner-case, requiring
a minimum of three closely-spaced database crashes and an unlucky
positioning of the second recovery's checkpoint record before you'd notice
any problem. But the consequences are dire enough that it's a must-fix.
Ross Reedstrom, a couple months back) and to detect timezones that are
using leap-second timekeeping. The unknown-zone-name test is pretty
heuristic and ugly, but it seems better than the old behavior of just
switching to GMT given a bad name. Also make DecodePosixTimezone() a
tad more robust.
on Linux and would have who knows what unpleasant effects on other platforms.
If you need another include file for Windows, then add it; don't go
messing with the semantics of every other port's include files.
Win32 port is now called 'win32' rather than 'win'
add -lwsock32 on Win32
make gethostname() be only used when kerberos4 is enabled
use /port/getopt.c
new /port/opendir.c routines
disable GUC unix_socket_group on Win32
convert some keywords.c symbols to KEYWORD_P to prevent conflict
create new FCNTL_NONBLOCK macro to turn off socket blocking
create new /include/port.h file that has /port prototypes, move
out of c.h
new /include/port/win32_include dir to hold missing include files
work around ERROR being defined in Win32 includes
only remnant of this failed experiment is that the server will take
SET AUTOCOMMIT TO ON. Still TODO: provide some client-side autocommit
logic in libpq.
the type OID and typmod of the underlying base type. Per discussions
a few weeks ago with Andreas Pflug and others. Note that this behavioral
change affects both old- and new-protocol clients.
This makes no difference for existing uses, but allows SelectSortFunction()
and pred_test_simple_clause() to use indexscans instead of seqscans to
locate entries for a particular operator in pg_amop. Better yet, they can
use the SearchSysCacheList() API to cache the search results.
dropped. The simplest fix for INSERT/UPDATE cases turns out to be for
preptlist.c to insert NULLs of a known-good type (I used INT4) rather
than making them match the deleted column's type. Since the representation
of NULL is actually datatype-independent, this should work fine.
I also re-reverted the patch to disable the use_physical_tlist optimization
in the presence of dropped columns. It still doesn't look worth the
trouble to be smarter, if there are no other bugs to fix.
Added a regression test to catch future problems in this area.
where the table contains dropped columns. If the columns are dropped,
then their types may be gone as well, which causes ExecTypeFromTL() to
fail if the dropped columns appear in a plan node's tlist. This could
be worked around but I don't think the optimization is valuable enough
to be worth the trouble.
detected during buffer dump to be labeled with the buffer location.
For example, if a page LSN is clobbered, we now produce something like
ERROR: XLogFlush: request 2C000000/8468EC8 is not satisfied --- flushed only
to 0/8468EF0
CONTEXT: writing block 0 of relation 428946/566240
whereas before there was no convenient way to find out which page had
been trashed.
dead xlog segments are not considered part of a critical section. It is
not necessary to force a database-wide panic if we get a failure in these
operations. Per recent trouble reports.
handle multiple 'formats' for data I/O. Restructure CommandDest and
DestReceiver stuff one more time (it's finally starting to look a bit
clean though). Code now matches latest 3.0 protocol document as far
as message formats go --- but there is no support for binary I/O yet.
the connection when appropriate.
This checkin also adds the type map for jdbc3, however currently it is
identical to the jdbc2 mapping.
Modified Files:
jdbc/org/postgresql/core/BaseStatement.java
jdbc/org/postgresql/core/QueryExecutor.java
jdbc/org/postgresql/jdbc3/AbstractJdbc3Connection.java
of Describe on a prepared statement. This was in the original 3.0
protocol proposal, but I took it out for reasons that seemed good at
the time. Put it back per yesterday's pghackers discussion.
Describe would claim that no tuples will be returned. Only affects
SELECTs added to non-SELECT base queries by rewrite rules. If you
want to see the output of such a select, you gotta use 'simple Query'
protocol.
DestReceiver pointers instead of just CommandDest values. The DestReceiver
is made at the point where the destination is selected, rather than
deep inside the executor. This cleans up the original kluge implementation
of tstoreReceiver.c, and makes it easy to support retrieving results
from utility statements inside portals. Thus, you can now do fun things
like Bind and Execute a FETCH or EXPLAIN command, and it'll all work
as expected (e.g., you can Describe the portal, or use Execute's count
parameter to suspend the output partway through). Implementation involves
stuffing the utility command's output into a Tuplestore, which would be
kind of annoying for huge output sets, but should be quite acceptable
for typical uses of utility commands.
the column by table OID and column number, if it's a simple column
reference. Along the way, get rid of reskey/reskeyop fields in Resdoms.
Turns out that representation was not convenient for either the planner
or the executor; we can make the planner deliver exactly what the
executor wants with no more effort.
initdb forced due to change in stored rule representation.
which does the same thing. Perhaps at one time there was a reason to
allow plan nodes to store their result types in different places, but
AFAICT that's been unnecessary for a good while.
avoids 'input buffer overflow' failure on long literals, improves
performance, gives the right answer for line position in functions
containing multiline literals, suppresses annoying compiler warnings,
and generally is so much better I wonder why we didn't do it before.
Per recent discussion on pgsql-general, this is appropriate for spec
compliance, and has the nice side-effect of easing porting from old
pg_dump files that exhibit the 59.999=>60.000 roundoff problem.
implementation limits, do not issue an ERROR; instead issue a NOTICE and use
the max supported value. Per pgsql-general discussion of 28-Apr, this is
needed to allow easy porting from pre-7.3 releases where the limits were
higher.
Unrelated change in same area: accept GLOBAL TEMP/TEMPORARY as a synonym
for TEMPORARY, as per pgsql-hackers discussion of 15-Apr. We previously
rejected it, but that was based on a misreading of the spec --- SQL92's
GLOBAL temp tables are really closer to what we have than their LOCAL ones.
per report from Olivier Prenant. Also fix off-by-one space calculation
in ReadToc; this woould not have hurt us until we had more than 100
dependencies for a single object, but wrong is wrong.
(agollapudi@demandsolutions.com).
Also applied the RefCursor support patch by Nic Ferrier. This patch allows
you too return a get a result set from a function that returns a refcursor.
For example:
call.registerOutParameter(1, Types.OTHER);
call.execute();
ResultSet rs = (ResultSet) call.getObject(1);
Modified Files:
jdbc/org/postgresql/core/BaseStatement.java
jdbc/org/postgresql/jdbc1/AbstractJdbc1ResultSet.java
jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
jdbc/org/postgresql/jdbc1/Jdbc1CallableStatement.java
jdbc/org/postgresql/jdbc1/Jdbc1PreparedStatement.java
jdbc/org/postgresql/jdbc1/Jdbc1Statement.java
jdbc/org/postgresql/jdbc2/AbstractJdbc2ResultSet.java
jdbc/org/postgresql/jdbc2/Jdbc2CallableStatement.java
jdbc/org/postgresql/jdbc2/Jdbc2PreparedStatement.java
jdbc/org/postgresql/jdbc2/Jdbc2Statement.java
jdbc/org/postgresql/jdbc3/Jdbc3CallableStatement.java
jdbc/org/postgresql/jdbc3/Jdbc3PreparedStatement.java
jdbc/org/postgresql/jdbc3/Jdbc3Statement.java
Added Files:
jdbc/org/postgresql/PGRefCursorResultSet.java
jdbc/org/postgresql/jdbc1/Jdbc1RefCursorResultSet.java
jdbc/org/postgresql/jdbc2/Jdbc2RefCursorResultSet.java
jdbc/org/postgresql/jdbc3/Jdbc3RefCursorResultSet.java
jdbc/org/postgresql/test/jdbc2/RefCursorTest.java
