changes, but I kept finding myself wishing I could see what schema a
table or view exists in when I use \dt, \dv, etc. So, here is a patch
which does just that.
It sorts on "Schema" first, and "Name" second.
It also changes the test for system objects to key off the namespace
name starting with 'pg_' instead of the object name.
Sample output:
test=# create schema testschema;
CREATE SCHEMA
test=# create view testschema.ts_view as select 1;
CREATE VIEW
test=# \dv
List of relations
Name | Schema | Type | Owner
--------------------+------------+------+----------
__testpassbyval | public | view | postgres
fooview | public | view | postgres
master_pg_proc | public | view | postgres
rmt_pg_proc | public | view | postgres
vw_dblink_get_pkey | public | view | postgres
vw_dblink_replace | public | view | postgres
ts_view | testschema | view | postgres
(7 rows)
Joe Conway
> submitted on July 9:
>
> http://archives.postgresql.org/pgsql-patches/2002-07/msg00056.php
>
> Please disregard that one *if* this one is applied. If this one is
> rejected please go ahead with the July 9th patch.
The July 9th Table Function API patch mentioned above is now in CVS, so
here is an updated version of the guc patch which should apply cleanly
against CVS tip.
Joe Conway
.
So i took the opportunity to fix some stuff:
1. Made the thing compile (typos & needed definitions) with the new pqsecure_* s
tuff, and added fe-secure.c to the win32.mak makefile.
2. Fixed some MULTIBYTE compile errors (when building without MB support).
3. Made it do that you can build with debug info: "nmake -f win32.mak DEBUG=1".
4. Misc small compiler speedup changes.
The resulting .dll has been tested in production, and everything seems ok.
I CC:ed -hackers because i'm not sure about two things:
1. In libpq-int.h I typedef ssize_t as an int because Visual C (v6.0)
doesn't de fine ssize_t. Is that ok, or is there any standard about what
type should be use d for ssize_t?
2. To keep the .dll api consistent regarding MULTIBYTE I just return -1
in fe-connect.c:PQsetClientEncoding() instead of taking away the whole
function. I wonder if i should do any compares with the
conn->client_encoding and return 0 if not hing would have changed (if so
how do i check that?).
Regards
Magnus Naeslund
bitmap, if present).
Per Tom Lane's suggestion the information whether a tuple has an oid
or not is carried in the tuple descriptor. For debugging reasons
tdhasoid is of type char, not bool. There are predefined values for
WITHOID, WITHOUTOID and UNDEFOID.
This patch has been generated against a cvs snapshot from last week
and I don't expect it to apply cleanly to current sources. While I
post it here for public review, I'm working on a new version against a
current snapshot. (There's been heavy activity recently; hope to
catch up some day ...)
This is a long patch; if it is too hard to swallow, I can provide it
in smaller pieces:
Part 1: Accessor macros
Part 2: tdhasoid in TupDesc
Part 3: Regression test
Part 4: Parameter withoid to heap_addheader
Part 5: Eliminate t_oid from HeapTupleHeader
Part 2 is the most hairy part because of changes in the executor and
even in the parser; the other parts are straightforward.
Up to part 4 the patched postmaster stays binary compatible to
databases created with an unpatched version. Part 5 is small (100
lines) and finally breaks compatibility.
Manfred Koizar
PX recombination operator, changes some elog() messages from LOG
to DEBUG1, puts some debugging functions inside the appropriate
#ifdef (not enabled by default), and makes a few other minor
cleanups.
BTW, the elog() change is motivated by at least one user who
has sent a concerned email to -general asking exactly what the
"ERX recombination operator" is, and what it is doing to their
DBMS.
Neil Conway
tuple header. The fix is based on the thought that HEAP_MOVED_IN is
not needed any more as soon as HEAP_XMIN_COMMITTED has been set. So
in tqual.c and vacuum.c the HEAP_MOVED bits are cleared when
HEAP_XMIN_COMMITTED is set.
Vacuum robustness is enhanced by rearranging ifs, so that we have a
chance to elog(ERROR, ...) before an assertion fails.
A new regression test is included.
Manfred Koizar
> Hi Tatsuo,
>
> I've attached a patch for the version of pgbench in CVS. It includes the
> following changes:
>
> - fix some spelling mistakes, indentation stuff, etc.
>
> - minor code cleanup -- (void) args instead of (), etc.
>
> - allocate the state array dynamically, so that it is only as
> large as needed. This reduces the memory consumption of pgbench
> slightly, and makes a larger MAXCLIENTS setting possible
>
> - (the only controversial change) add an option "-l" to log
> transaction latencies to a file. The "transaction latency"
> is the time between when the BEGIN is issued and the transaction
> commits. This is written to a file, along with the client #
> and the transaction #. The data in the file can then be used
> for things like:
>
> - consistency analysis: is the TPS the same through the
> entire run of pgbench, or does it change?
>
> - more detailed stats: what is the average latency, worse-case
> latency, best-case latency?
>
> - graphs: feed the data to gnuplot, graph latency versus. time
>
> - etc.
>
> I was going to store this data in memory and write it to disk
> at the end of the pgbench run, but that isn't feasible because
> the data can be very large: for example, ~70MB if benchmarking
> 128 clients doing 100,000 transactions each.
>
> Cheers,
>
> Neil
extension to create binary compatible casts. Includes dependency tracking
as well.
pg_proc.proimplicit is now defunct, but will be removed in a separate
commit.
pg_dump provides a migration path from the previous scheme to declare
casts. Dumping binary compatible casts is currently impossible, though.
reflects the changes in the tablefunc-fix patch that I sent in the other
day. It also refers to "see contrib/tablefunc for more examples", which
is next on my list of things to finish and submit.
Joe Conway
COPY x (a,d,c,b) from stdin;
COPY x (a,c) to stdout;
as well as the corresponding changes to pg_dump to use the new
functionality. This functionality is not available when using
the BINARY option. If a column is not specified in the COPY FROM
statement, its default values will be used.
In addition to this functionality, I tweaked a couple of the
error messages emitted by the new COPY <options> checks.
Brent Verner
Implements between (symmetric / asymmetric) as a node.
Executes the left or right expression once, makes a Const out of the
resulting Datum and executes the >=, <= portions out of the Const sets.
Of course, the parser does a fair amount of preparatory work for this to
happen.
Rod Taylor
Conway (BuildTupleFromCStrings sets NULL for pass-by-value types when
intended value is 0). It also implements some other improvements
suggested by Neil.
Joe Conway
conversion procs and conversions are added in initdb. Currently
supported conversions are:
UTF-8(UNICODE) <--> SQL_ASCII, ISO-8859-1 to 16, EUC_JP, EUC_KR,
EUC_CN, EUC_TW, SJIS, BIG5, GBK, GB18030, UHC,
JOHAB, TCVN
EUC_JP <--> SJIS
EUC_TW <--> BIG5
MULE_INTERNAL <--> EUC_JP, SJIS, EUC_TW, BIG5
Note that initial contents of pg_conversion system catalog are created
in the initdb process. So doing initdb required is ideal, it's
possible to add them to your databases by hand, however. To accomplish
this:
psql -f your_postgresql_install_path/share/conversion_create.sql your_database
So I did not bump up the version in cataversion.h.
TODO:
Add more conversion procs
Add [CASCADE|RESTRICT] to DROP CONVERSION
Add tuples to pg_depend
Add regression tests
Write docs
Add SQL99 CONVERT command?
--
Tatsuo Ishii