| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
| |
keys, rather than a single trigger for both events. This should not change
functionality, but it is more consistent: previously, there were trigger
functions for both "check_insert" and "check_update", but the former was
used for both events.
Bump catalog version number (not strictly necessary, but best to be
cautious).
|
|
|
|
| |
a FOR UPDATE clause, if one is present.
|
|
|
|
|
| |
cstring, rather than text, so as to eliminate useless conversions
inside the parser. Per recent discussion.
|
|
|
|
|
|
| |
would be evaluated only once anyway (ie, it's just a SELECT with no
FROM or an INSERT ... VALUES). The planner can't do it any faster than
the executor, so no point in an extra copying of the expression tree.
|
|
|
|
|
|
| |
pg_class_aclmask(). We only need to do this when we have to check
pg_shadow.usecatupd, and that's not relevant unless the target table
is a system catalog. So we can usually avoid one syscache lookup.
|
|
|
|
|
|
|
|
| |
are now reported via elog, eliminating the need to test the result code
at most call sites. Make it possible for the caller to distinguish a
freshly acquired lock from one already held in the current transaction.
Use that capability to avoid redundant AcceptInvalidationMessages() calls
in LockRelation().
|
|
|
|
|
|
| |
status of the most recently queried userid. Since the common pattern is
many successive queries about the same user (ie, the current user) this
can save a lot of syscache probes.
|
|
|
|
| |
which is a common case.
|
|
|
|
| |
of a query.
|
|
|
|
|
|
|
|
| |
were pretty expensive and I believe the case they were put in to
defend against can no longer arise, now that we have dependency checks
to prevent deletion of a type entry that is still referenced. Certainly
the example given in the CVS log entry can't happen anymore.
Since this was the only use of typeidIsValid(), remove the routine too.
|
|
|
|
|
|
| |
to columns of an RTE that was a function returning RECORD with a column
definition list. Apparently no one has tried to use non-default typmod
with a function returning RECORD before.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
spotted by Qingqing Zhou. The HASH_ENTER action now automatically
fails with elog(ERROR) on out-of-memory --- which incidentally lets
us eliminate duplicate error checks in quite a bunch of places. If
you really need the old return-NULL-on-out-of-memory behavior, you
can ask for HASH_ENTER_NULL. But there is now an Assert in that path
checking that you aren't hoping to get that behavior in a palloc-based
hash table.
Along the way, remove the old HASH_FIND_SAVE/HASH_REMOVE_SAVED actions,
which were not being used anywhere anymore, and were surely too ugly
and unsafe to want to see revived again.
|
|
|
|
|
|
| |
hash table. This is a pretty unlikely scenario, since the table
should be tiny, but we can't guarantee continued correct operation
if it does occur. Spotted by Qingqing Zhou.
|
|
|
|
|
|
| |
from a RECORD Const node, because that's what it may be faced with
after constant-folding of a function returning RECORD. Per example
from Michael Fuhr.
|
|
|
|
|
|
|
|
|
|
|
|
| |
routines in the index's relcache entry, instead of doing a fresh fmgr_info
on every index access. We were already doing this for the index's opclass
support functions; not sure why we didn't think to do it for the AM
functions too. This supersedes the former method of caching (only)
amgettuple in indexscan scan descriptors; it's an improvement because the
function lookup can be amortized across multiple statements instead of
being repeated for each statement. Even though lookup for builtin
functions is pretty cheap, this seems to drop a percent or two off some
simple benchmarks.
|
|
|
|
|
| |
consistency and to prevent rounding for days < 30. Also round off all
trailing zeros, rather than leaving an even number of digits.
|
| |
|
| |
|
|
|
|
| |
Marko Kreen
|
|
|
|
| |
used. From Jaime Casanova.
|
| |
|
|
|
|
|
|
| |
Display only 9 not 10 digits of precision for timestamp values when
using non-integer timestamps. This prevents the display of rounding
errors for common values like days < 32.
|
| |
|
|
|
|
|
| |
using non-integer timestamps. This prevents the display of rounding
errors for common values like days < 32.
|
|
|
|
| |
correctly, style fixes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
working buffer into ParseDateTime() and reject too-long input there,
rather than checking the length of the input string before calling
ParseDateTime(). The old method was bogus because ParseDateTime() can use
a variable amount of working space, depending on the content of the
input string (e.g. how many fields need to be NUL terminated). This fixes
a minor stack overrun -- I don't _think_ it's exploitable, although I
won't claim to be an expert.
Along the way, fix a bug reported by Mark Dilger: the working buffer
allocated by interval_in() was too short, which resulted in rejecting
some perfectly valid interval input values. I added a regression test for
this fix.
|
|
|
|
|
|
|
|
| |
scanner anyway) to avoid having any backup states. According to the
flex manual, this should speed things up, and indeed the backend scanner
is about a third faster according to some quick profiling checks.
I haven't tried to measure the speed change in psql, but it probably
is similar.
|
|
|
|
|
|
| |
error.
Pavel Stehule
|
|
|
|
|
|
|
|
|
|
| |
using pg_mblen. Therefore, pg_mblen is executed many times, and it
becomes a bottleneck.
This patch makes a short cut, and reduces execution frequency of
pg_mblen by comparing the first byte first.
a_ogawa
|
|
|
|
|
|
|
|
|
| |
about adding an errant "TO" when we already have a TO. Since
TO cannot be a valid column name (we must quote it), we can
simply ignore the tab-completion if the previous word
was a "TO".
Greg Sabino Mullane
|
|
|
|
| |
them, the executation behavior could be unexpected.
|
|
|
|
|
|
|
| |
where there was also a WHERE-clause restriction that applied to the
join. The check on restrictlist == NIL is really unnecessary anyway,
because select_mergejoin_clauses already checked for and complained
about any unmergejoinable join clauses. So just take it out.
|
| |
|
|
|
|
|
| |
Not sure why this hasn't been reported before; perhaps it is not needed
with newer gcc versions, but it definitely fails here.
|
|
|
|
|
|
| |
if they are two-byte multibyte characters. Same thing can be happen
if octet_length(multibyte_chars) == n where n is char(n).
Long standing bug since 7.3 days. Per report and fix from Yoshiyuki Asaba.
|
|
|
|
| |
Andrew Dunstan.
|
| |
|
|
|
|
| |
Log prepare query during execute. Bruce Momjian
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
#define SECS_PER_DAY 86400
#define USECS_PER_DAY INT64CONST(86400000000)
#define USECS_PER_HOUR INT64CONST(3600000000)
#define USECS_PER_MINUTE INT64CONST(60000000)
#define USECS_PER_SEC INT64CONST(1000000)
|
| |
|
|
|
|
|
|
|
| |
that we acquire a lock on relations added to the query due to inheritance.
Formerly, no such lock was held throughout planning, which meant that
a schema change could occur to invalidate the plan before it's even
been completed.
|
|
|
|
| |
sharing of %_SHARED. From Andrew Dunstan.
|
|
|
|
|
|
|
|
|
| |
aren't doing anything useful (ie, neither selection nor projection).
Also, extend to SubqueryScan the hacks already in place to avoid
unnecessary ExecProject calls when the result would just be the same
tuple the subquery already delivered. This saves some overhead in
UNION and other set operations, as well as avoiding overhead for
unflatten-able subqueries. Per example from Sokolov Yura.
|
| |
|
|
|
|
|
|
| |
code to better handle writethrough.
Chris Campbell
|
|
|
|
|
|
|
|
| |
from Abhijit Menon-Sen, minor editorialization from Neil Conway. Also,
improve md5(text) to allocate a constant-sized buffer on the stack
rather than via palloc.
Catalog version bumped.
|
| |
|