review/feedback if anyone is interested and can spend the time. But I'd
also love to get this committed and address changes as incremental
patches ;-), so if there are no objections, please apply.
Below I'll give a synopsis of the changes. More detailed descriptions
are now in a new doc directory under contrib/dblink. There is also a new
dblink.test.sql file which will give a pretty good overview of the
functions and their use.
Joe Conway
already fixed by You. However there were a few left and attached patch
should fix the rest of them.
I used StringInfo only in 2 places and both of them are inside debug
ifdefs. Only performance penalty will come from using strlen() like all
the other code does.
I also modified some of the already patched parts by changing
snprintf(buf, 2 * BUFSIZE, ... style lines to
snprintf(buf, sizeof(buf), ... where buf is an array.
Jukka Holappa
function, connectby(), which can serve as a reference implementation for
the changes made in the last few days -- namely the ability of a
function to return an entire tuplestore, and the ability of a function
to make use of the query provided "expected" tuple description.
Description:
connectby(text relname, text keyid_fld, text parent_keyid_fld,
text start_with, int max_depth [, text branch_delim])
- returns keyid, parent_keyid, level, and an optional branch string
- requires anonymous composite type syntax in the FROM clause. See
the instructions in the documentation below.
Joe Conway
(overlaying low byte of page size) and add HEAP_HASOID bit to t_infomask,
per earlier discussion. Simplify scheme for overlaying fields in tuple
header (no need for cmax to live in more than one place). Don't try to
clear infomask status bits in tqual.c --- not safe to do it there. Don't
try to force output table of a SELECT INTO to have OIDs, either. Get rid
of unnecessarily complex three-state scheme for TupleDesc.tdhasoids, which
has already caused one recent failure. Improve documentation.
diffs to 7.3-devel and may not be applicable to 7.2. I have included a
change covered by a previous bugfix patch I submitted (the problem with
-.1 not being accepted by cube_in). It does not include a fix for the
potential buffer overrun issue I reported for cube_yyerror in
cubeparse.y.
Bruno Wolff III
to the table function, thus preventing memory leakage accumulation across
calls. This means that SRFs need to be careful to distinguish permanent
and local storage; adjust code and documentation accordingly. Patch by
Joe Conway, very minor tweaks by Tom Lane.
array header, and to compute sizing and alignment of array elements
the same way normal tuple access operations do --- viz, using the
tupmacs.h macros att_addlength and att_align. This makes the world
safe for arrays of cstrings or intervals, and should make it much
easier to write array-type-polymorphic functions; as examples see
the cleanups of array_out and contrib/array_iterator. By Joe Conway
and Tom Lane.
with OPAQUE, as per recent pghackers discussion. I still want to do some
more work on the 'cstring' pseudo-type, but I'm going to commit the bulk
of the changes now before the tree starts shifting under me ...
snprintf() in contrib/. I didn't touch the places where pointer
arithmatic was being used, or other areas where the fix wasn't
trivial. I would think that few, if any, of the usages of sprintf()
were actually exploitable, but it's probably better to be paranoid...
Neil Conway
composite type capability makes it possible to create a system view
based on a table function in a way that is hopefully palatable to
everyone. The attached patch takes advantage of this, moving
show_all_settings() from contrib/tablefunc into the backend (renamed
all_settings(). It is defined as a builtin returning type RECORD. During
initdb a system view is created to expose the same information presently
available through SHOW ALL. For example:
test=# select * from pg_settings where name like '%debug%';
name | setting
-----------------------+---------
debug_assertions | on
debug_pretty_print | off
debug_print_parse | off
debug_print_plan | off
debug_print_query | off
debug_print_rewritten | off
wal_debug | 0
(7 rows)
Additionally during initdb two rules are created which make it possible
to change settings by updating the system view -- a "virtual table" as
Tom put it. Here's an example:
Joe Conway
Christopher Kings-Lynne wrote:
> I'm still getting ltree failures on 64bit freebsd:
>
> sed 's,MODULE_PATHNAME,$libdir/ltree,g' ltree.sql.in >ltree.sql
> gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPI
> C -DLOWER_NODE -I. -I../../src/include -c -o ltree_io.o ltree_io.c -MMD
> ltree_io.c: In function `ltree_in':
> ltree_io.c:57: warning: int format, different type arg (arg 3)
> ltree_io.c:63: warning: int format, different type arg (arg 4)
> ltree_io.c:68: warning: int format, different type arg (arg 3)
Teodor Sigaev
1. Reworked patch from Andrey Oktyabrski (ano@spider.ru) with
functions: icount, sort, sort_asc, uniq, idx, subarray
operations: #, +, -, |, &
FUNCTIONS:
int icount(int[]) - the number of elements in intarray
int[] sort(int[], 'asc' | 'desc') - sort intarray
int[] sort(int[]) - sort in ascending order
int[] sort_asc(int[]),sort_desc(int[]) - shortcuts for sort
int[] uniq(int[]) - returns unique elements
int idx(int[], int item) - returns index of first intarray matching element
to item, or '0' if matching failed.
int[] subarray(int[],int START [, int LEN]) - returns part of intarray
starting from element number START (from 1)
and length LEN.
OPERATIONS:
int[] && int[] - overlap - returns TRUE if arrays has at least one common elements.
int[] @ int[] - contains - returns TRUE if left array contains right array
int[] ~ int[] - contained - returns TRUE if left array is contained in right array
# int[] - return the number of elements in array
int[] + int - push element to array ( add to end of array)
int[] + int[] - merge of arrays (right array added to the end of left one)
int[] - int - remove entries matched by right argument from array
int[] - int[] - remove left array from right
int[] | int - returns intarray - union of arguments
int[] | int[] - returns intarray as a union of two arrays
int[] & int[] - returns intersection of arrays
Oleg Bartunov
has_language_privilege, has_schema_privilege to let SQL queries test
all the new privilege types in 7.3. Also, add functions pg_table_is_visible,
pg_type_is_visible, pg_function_is_visible, pg_operator_is_visible,
pg_opclass_is_visible to test whether objects contained in schemas are
visible in the current search path. Do some minor cleanup to centralize
accesses to pg_database, as well.
> please find attached patch to current CVS ( contrib/ltree)
> Version for 7.2 is distributed as separate package -
I believe that patch also intended to remove contrib/ltree/patch.72
code review by Tom Lane. Remaining issues: functions that take or
return tuple types are likely to break if one drops (or adds!)
a column in the table defining the type. Need to think about what
to do here.
Along the way: some code review for recent COPY changes; mark system
columns attnotnull = true where appropriate, per discussion a month ago.
three functions which exercise the tablefunc API.
show_all_settings()
- returns the same information as SHOW ALL, but as a query result
normal_rand(int numvals, float8 mean, float8 stddev, int seed)
- returns a set of normally distributed float8 values
- This routine implements Algorithm P (Polar method for normal
deviates) from Knuth's _The_Art_of_Computer_Programming_, Volume 2,
3rd ed., pages 122-126. Knuth cites his source as "The polar
method", G. E. P. Box, M. E. Muller, and G. Marsaglia,
_Annals_Math,_Stat._ 29 (1958), 610-611.
crosstabN(text sql)
- returns a set of row_name plus N category value columns
- crosstab2(), crosstab3(), and crosstab4() are defined for you,
but you can create additional crosstab functions per directions
in the README.
Joe Conway
documentation (xindex.sgml should be rewritten), need to teach pg_dump
about it, need to update contrib modules that currently build pg_opclass
entries by hand. Original patch by Bill Studenmund, grammar adjustments
and general update for 7.3 by Tom Lane.
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
> 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
Bruce Momjian