| Age | Commit message (Collapse) | Author |
|---|
|
|
|
pointed out by Peter.
|
|
|
|
|
|
|
|
|
|
failures in SQL functions, due to forward references or unqualified
references to objects in other schemas. Per recent discussion.
|
|
of function bodies is done at CREATE FUNCTION time. This is normally
true but can be set false to avoid problems with forward references,
wrong schema search path, etc. This is just the backend patch, still
need to adjust pg_dump to make use of it.
|
|
than generating an invalid output string. Per observation and patch
from Igor Shevchenko. Further code cleanup and documentation by
Tom Lane.
|
|
Also remove -g, which has no business in CPPFLAGS in the first place,
let alone being hardwired there by a sub-Makefile.
|
|
|
|
to make them comparable to what UpdateStats does in the same situation.
I'm not certain two instances of vac_update_relstats could run in
parallel for the same relation, but parallel invocations of vac_update_dbstats
do seem possible.
|
|
in the schema search path. Otherwise pg_dump doesn't correctly dump
scenarios where a custom opclass is created in 'public' and then used
by indexes in other schemas.
|
|
processing the request; this ensures that the request won't be taken
to cancel a subsequently-issued query. Race condition originally
noted by Oliver Jowett in the context of JDBC, but libpq has it too.
|
|
|
|
from Patrick Welche
|
|
|
|
developed on -hackers.
|
|
longer conveys useful information.
|
|
and try to coerce the values to boolean if not. Per recent discussions.
|
|
discussion on pgsql-hackers: in READ COMMITTED mode we just have to force
a QuerySnapshot update in the trigger, but in SERIALIZABLE mode we have
to run the scan under a current snapshot and then complain if any rows
would be updated/deleted that are not visible in the transaction snapshot.
|
|
Per gripe from Gaetano Mendola.
|
|
invalid (has the wrong magic number) until the build is entirely
complete. This turns out to cost no additional writes in the normal
case, since we were rewriting the metapage at the end of the process
anyway. In normal scenarios there's no real gain in security, because
a failed index build would roll back the transaction leaving an unused
index file, but for rebuilding shared system indexes this seems to add
some useful protection.
|
|
discussed on pghackers.
|
|
type name specification.
Jan
|
|
Before patch:
test=# select pg_get_constraintdef(oid) from pg_constraint;
pg_get_constraintdef
-------------------------------------------------------------------------------------------------
CHECK (VALUE >= 0)
CHECK ((((a)::text = 'asdf'::text) OR ((a)::text = 'fdsa'::text)) OR
((a)::text = 'dfd'::text))
PRIMARY KEY (b)
FOREIGN KEY (a) REFERENCES test2(b)
UNIQUE (b)
(5 rows)
test=# select pg_get_constraintdef(oid, true) from pg_constraint;
pg_get_constraintdef
-----------------------------------------------------------------------------------
CHECK VALUE >= 0
CHECK a::text = 'asdf'::text OR a::text = 'fdsa'::text OR a::text =
'dfd'::text
PRIMARY KEY (b)
FOREIGN KEY (a) REFERENCES test2(b)
UNIQUE (b)
(5 rows)
After patch:
test=# select pg_get_constraintdef(oid) from pg_constraint;
pg_get_constraintdef
-------------------------------------------------------------------------------------------------
CHECK (VALUE >= 0)
CHECK ((((a)::text = 'asdf'::text) OR ((a)::text = 'fdsa'::text)) OR
((a)::text = 'dfd'::text))
PRIMARY KEY (b)
FOREIGN KEY (a) REFERENCES test2(b)
UNIQUE (b)
(5 rows)
test=# select pg_get_constraintdef(oid, true) from pg_constraint;
pg_get_constraintdef
-----------------------------------------------------------------------------------
CHECK (VALUE >= 0)
` CHECK (a::text = 'asdf'::text OR a::text = 'fdsa'::text OR a::text =
'dfd'::text)
PRIMARY KEY (b)
FOREIGN KEY (a) REFERENCES test2(b)
UNIQUE (b)
(5 rows)
It's important that those brackets are there to (a) match all other
constraints and (b) so that people can just copy and paste them and it
will work as SQL.
Christopher Kings-Lynne
|
|
this query?" logic in postgres.c
Also, make it print "duration:" like log_duration.
Neil Conway
|
|
don't deal well with tuples having dropped columns. The attached fixes
the issue. Please apply.
Joe Conway
|
|
> > a) Write documentation how the win32 console needs to be set up so that
> > psql can handle 8-bit characters.
> > Where should it be added? The Section "Installation on Windows" in the
> > Administrator's Guide seems natural to me.
> >
> > b) Add code to psql that prints a warning on startup of psql when the
> > console codepage differs from the windows codepage, something like
> >
> > Warning: Console codepage (850) differs from windows codepage (1252)
> > 8-bit characters will not work correctly. See PostgreSQL
> > documentation "Installation on Windows" for details.
>
Attached are two patches:
- installdoc.patch contains an additional paragraph on the win32 console
codepage for the chapter "Installation on Windows"
Due to a lack of SGML-tools, I have only edited the text and not tested
the SGML code - please check it before merging into the CVS branch.
- psqlcodepage.patch adds the warning about a problematic codepage to psql.
Christoph Dalitz
|
|
changes between 7.3 and 7.4, for example quoting and function names.
|
|
were they doing here anyway?
|
|
|
|
|
|
this should help people get started in 7.4 as well.
|
|
|
|
|
|
|
|
Also, make :alnum: character class directly dependent on isalnum()
rather than guessing.
|
|
|
|
|
|
to be less dangerous, and often faster as well. ExprState trees are
not kept across transaction boundaries; this eliminates problems with
resource leakage in failed transactions. But by keeping them in a
per-transaction EState, we can safely arrange for a single ExprState
to be shared by all the expression evaluations done in a given plpgsql
function call. (Formerly it seemed necessary to create and destroy an
ExprState for each exec_eval_simple_expr() call.) This saves time in
any scenario where a plpgsql function executes more than one expression.
Seems to be about as fast as 7.3 for simple cases, and significantly
faster for functions that do a lot of calculations.
|
|
post-abort cleanup hooks. I'm surprised that we have not needed this
already, but I need it now to fix a plpgsql problem, and the usefulness
for other dynamically loaded modules seems obvious.
|
|
in the RI triggers for ON DELETE/UPDATE SET DEFAULT. The code depended
way too much on knowledge of plan structure, and yet still would fail
if the generated query got rewritten by rules.
|
|
Nigel J. Andrews
|
|
|
|
|
|
sequence for dumping.
|
|
|
|
|
|
|
