| Age | Commit message (Collapse) | Author |
|---|
|
|
|
(materialization into a tuple store) discussed on pgsql-hackers earlier.
I've updated the documentation and the regression tests.
Notes on the implementation:
- I needed to change the tuple store API slightly -- it assumes that it
won't be used to hold data across transaction boundaries, so the temp
files that it uses for on-disk storage are automatically reclaimed at
end-of-transaction. I added a flag to tuplestore_begin_heap() to control
this behavior. Is changing the tuple store API in this fashion OK?
- in order to store executor results in a tuple store, I added a new
CommandDest. This works well for the most part, with one exception: the
current DestFunction API doesn't provide enough information to allow the
Executor to store results into an arbitrary tuple store (where the
particular tuple store to use is chosen by the call site of
ExecutorRun). To workaround this, I've temporarily hacked up a solution
that works, but is not ideal: since the receiveTuple DestFunction is
passed the portal name, we can use that to lookup the Portal data
structure for the cursor and then use that to get at the tuple store the
Portal is using. This unnecessarily ties the Portal code with the
tupleReceiver code, but it works...
The proper fix for this is probably to change the DestFunction API --
Tom suggested passing the full QueryDesc to the receiveTuple function.
In that case, callers of ExecutorRun could "subclass" QueryDesc to add
any additional fields that their particular CommandDest needed to get
access to. This approach would work, but I'd like to think about it for
a little bit longer before deciding which route to go. In the mean time,
the code works fine, so I don't think a fix is urgent.
- (semi-related) I added a NO SCROLL keyword to DECLARE CURSOR, and
adjusted the behavior of SCROLL in accordance with the discussion on
-hackers.
- (unrelated) Cleaned up some SGML markup in sql.sgml, copy.sgml
Neil Conway
|
|
|
|
> o -Allow cursors outside transactions
|
|
functions
* Document pg_conversion_is_visible() which was created in one of my
previous patches and didn't get documented for some reason
Christopher Kings-Lynne
|
|
|
|
vague cross-references with real links.
|
|
|
|
|
|
Keep PQfreeNotify() around for binary compatibility.
|
|
when autocommit is off, and document grouping when autocommit is on.
|
|
|
|
them as arrays of the internal datatype. This requires treating the
stavalues columns as 'anyarray' rather than 'text[]', which is not 100%
kosher but seems to work fine for the purposes we need for pg_statistic.
Perhaps in the future 'anyarray' will be allowed more generally.
|
|
|
|
+ <entry><function>hostmask</function>(<type>inet</type>)</entry>
+ <entry><type>inet</type></entry>
+ <entry>construct hostmask for network</entry>
+ <entry><literal>hostmask('192.168.23.20/30')</literal></entry>
+ <entry><literal>0.0.0.3</literal></entry>
Greg Wickham
|
|
|
|
> * -Change NUMERIC data type to use base 10,000 internally
|
|
some of the algorithms for higher functions. I see about a factor of ten
speedup on the 'numeric' regression test, but it's unlikely that that test
is representative of real-world applications.
initdb forced due to change of on-disk representation for NUMERIC.
|
|
effectively used to mean a default value that could also be spelled
out explicitly. (ACLs behave that way, and useconfig/datconfig
do too IIRC.)
It's a bit of a hack, but it saves table space and backend code ---
without this convention the default would have to be inserted "manually"
since we have no mechanism to supply defaults when C code is forming a
new catalog tuple.
I'm inclined to leave the code alone. But Alvaro is right that it'd be
good to point out the 'infinity' option in the CREATE USER and ALTER
USER man pages. (Doc patch please?)
Alvaro Herrera
|
|
join is defined as:
from_item [ NATURAL ] join_type from_item
[ ON join_condition | USING ( join_column_list ) ]
However, if the join_type is an INNER or OUTER join, an ON, USING, or
NATURAL clause *must* be specified (it's not optional, as that segment
of the docs suggest).
I'm not exactly sure what the best way to fix this is, so I've attached
a patch adding a FIXME comment to the relevant section of the SGML. If
anyone has any ideas on the proper way to outline join syntax, please
speak up.
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
|
|
a trigger as its parameter. It is basically copied from the pg_dump
code.
Christopher Kings-Lynne
|
|
be simplified (I'd thought that it can even be removed). This patch
does that.
Alvaro Herrera
|
|
Alvaro Herrera
|
|
queries while the rest remain blank.
Kevin Brown
|
|
|
|
|
|
Add ALTER SEQUENCE to modify min/max/increment/cache/cycle values
Also updated create sequence docs to mention NO MINVALUE, & NO MAXVALUE.
New Files:
doc/src/sgml/ref/alter_sequence.sgml
src/test/regress/expected/sequence.out
src/test/regress/sql/sequence.sql
ALTER SEQUENCE is NOT transactional. It behaves similarly to setval().
It matches the proposed SQL200N spec, as well as Oracle in most ways --
Oracle lacks RESTART WITH for some strange reason.
--
Rod Taylor <rbt@rbt.ca>
|
|
> o -Add ALTER SEQUENCE to modify min/max/increment/cache/cycle values
|
|
Lennert Buytenhek
|
|
Envrironment and Files section, explained exactly what -w
does)
This is a patch which allows pg_ctl to make an intelligent
guess as to the proper port when running 'psql -l' to
determine if the database has started up (the -w flag).
The environment variable PGPORT is used. If that is not found,
it checks if a specific port has been set inside the postgresql.conf
file. If it is has not, it uses the port that Postgres was
compiled with.
Greg Sabino Mullane greg@turnstep.com
|
|
> weird behavior across fork boundaries; (b) the additional memory space
> that has to be duplicated into child processes will cost something per
> child launch, even if the child never uses it. But these are only
> arguments that it might not *always* be a prudent thing to do, not that
> we shouldn't give the DBA the tool to do it if he wants. So fire away.
Here is a patch for the above, including a documentation update. It
creates a new GUC variable "preload_libraries", that accepts a list in
the form:
preload_libraries = '$libdir/mylib1:initfunc,$libdir/mylib2'
If ":initfunc" is omitted or not found, no initialization function is
executed, but the library is still preloaded. If "$libdir/mylib" isn't
found, the postmaster refuses to start.
In my testing with PL/R, it reduces the first call to a PL/R function
(after connecting) from almost 2 seconds, down to about 8 ms.
Joe Conway
|
|
Gavin Sherry
|
|
> * -Add start time to pg_stat_activity
|
|
Neil Conway
|
|
|
|
< * Rod is Rod Taylor <pg@rbt.ca)>
> * Rod is Rod Taylor <pg@rbt.ca>
|
|
connections, increase robustness, add NLS, and prepare for Windows port.
(vacuumdb and clusterdb will follow later.)
|
|
|
|
|
|
|
|
|
|
|
|
> * Allow UPDATE tab SET ROW (col, ...) = (...) for updating multiple columns
|
|
|
|
< * Add GUC log_statement_duration to print statement and >= min duration
> * Add GUC log_statement_and_duration to print statement and >= min duration
|
|
> * Add GUC log_statement_duration to print statement and >= min duration
|
|
|
|
for FETCH and MOVE.
|
|
Ian Barwick
|
|
utility statement (DeclareCursorStmt) with a SELECT query dangling from
it, rather than a SELECT query with a few unusual fields in it. Add
code to determine whether a planned query can safely be run backwards.
If DECLARE CURSOR specifies SCROLL, ensure that the plan can be run
backwards by adding a Materialize plan node if it can't. Without SCROLL,
you get an error if you try to fetch backwards from a cursor that can't
handle it. (There is still some discussion about what the exact
behavior should be, but this is necessary infrastructure in any case.)
Along the way, make EXPLAIN DECLARE CURSOR work.
|
