This one should work much better than the one I sent in previously. The
functionality is the same, but the patch was missing one file resulting
in
the compilation failing. The docs also received a minor fix.
Peter Eisentraut Sernanders väg 10:115
rate
it's better than what used to be there.
* Does proper SQL "host variable" substitution as pointed out by Andreas
Zeugwetter (thanks): select * from :foo; Also some changes in how ':'
and ';' are treated (escape with \ to send to backend). This does
_not_
affect the '::' cast operator, but perhaps others that contain : or ;
(but there are none right now).
* To show description with a <something> listing, append '?' to command
name, e.g., \df?. This seemed to be the convenient and logical
solution.
Or append a '+' to see more useless information, e.g., \df+.
* Fixed fflush()'ing bug pointed out by Jan during the regression test
discussion.
* Added LastOid variable. This ought to take care of TODO item "Add a
function to return the last inserted oid, for use in psql scripts"
(under CLIENTS)
E.g.,
insert into foo values(...);
insert into bar values(..., :LastOid);
\echo $LastOid
* \d command shows constraints, rules, and triggers defined on the table
(in addition to indices)
* Various fixes, optimizations, corrections
* Documentation update as well
Note: This now requires snprintf(), which, if necessary, is taken from
src/backend/port. This is certainly a little weird, but it should
suffice
until a source tree cleanup is done.
Enjoy.
--
Peter Eisentraut Sernanders väg 10:115
functions. One problem that I have encountered with the function
manager is that it does not allow the user to define type conversion
functions that convert between user types. For instance if mytype1,
mytype2, and mytype3 are three Postgresql user types, and if I wish to
define Postgresql conversion functions like
I run into problems, because the Postgresql dynamic loader would look
for a single link symbol, mytype3, for both pieces of object code. If
I just change the name of one of the Postgresql functions (to make the
symbols distinct), the automatic type conversion that Postgresql uses,
for example, when matching operators to arguments no longer finds the
type conversion function.
The solution that I propose, and have implemented in the attatched
patch extends the CREATE FUNCTION syntax as follows. In the first case
above I use the link symbol mytype2_to_mytype3 for the link object
that implements the first conversion function, and define the
Postgresql operator with the following syntax
The patch includes changes to the parser to include the altered
syntax, changes to the ProcedureStmt node in nodes/parsenodes.h,
changes to commands/define.c to handle the extra information in the AS
clause, and changes to utils/fmgr/dfmgr.c that alter the way that the
dynamic loader figures out what link symbol to use. I store the
string for the link symbol in the prosrc text attribute of the pg_proc
table which is currently unused in rows that reference dynamically
loaded
functions.
Bernie Frankpitt
No big deal; fixed lots of other markup at the same time.
Bigest change: make sure there is no whitespace
in front of <term> contents.
This will probably help the other output types too.
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
^^^^ required
Also note that SET TRANSACTION ISOLATION LEVEL change
isolevel for _current_ transaction, in accordance with
standard, not for session (ALTER SESSION is used in Oracle,
but it's not implemented currently).
And I would don't mention SET XACTISOLEVEL TO ...
form at all.
Please update set.sgml - I failed to understand all these
SET TIME ZONE { '<REPLACEABLE CLASS="PARAMETER">
now.
for Vadim
elements prior to CREATEing new ones. It is under control of the -c
command line option (with the default being status quo).
The DROP TRIGGER portion still needs implementation. Anyone able to
help clarify what exactly the CREATE TRIGGER portion does so I can fix
this?
Again, I have tried this with tables/indexes/sequences, but do not
have other schema elements in my database. As a result, I am not 100%
convinced that I got the syntax correct in all cases (but think I did,
nonetheless). If anyone can check the other cases, I'd appreciate it.
Cheers,
Brook
[I added manual page and sgml additions for the new -c option.]
> > the standard distribution. It occurs when a trigger calling this
> > function recursively fires another trigger which calls the same
> > function. The calling check_foreign_key loses its plan informantion and
> > when it tries to use it the backend closes its channel. You can check it
> > with the sql script I am attaching below.
> > The solution to this is to do a find_plan again before executing it at
> > line 483 of refint.c.
> > Therefore two more lines should be added before line 483:
Anand Surelia