- 08 Dec, 2000 5 commits
-
-
Hiroshi Inoue authored
-
Hiroshi Inoue authored
-
Tom Lane authored
or return type.
-
Tom Lane authored
or return type.
-
Tom Lane authored
or return type.
-
- 07 Dec, 2000 10 commits
-
-
Tom Lane authored
length is less than original string length.
-
Peter Eisentraut authored
-
Peter Eisentraut authored
-
Tom Lane authored
-
Tom Lane authored
As I read it, the spec requires a non-null result in some cases where one of the inputs is NULL: specifically, if the other endpoint of that interval is between the endpoints of the other interval, then the result is known TRUE despite the missing endpoint. The spec could've been a lot simpler if they did not intend this behavior. I did not force an initdb for this change, but if you don't do one you'll still see the old strict-function behavior.
-
Hiroshi Inoue authored
if the transaction has already been committed ?
-
Tom Lane authored
-
Tom Lane authored
-
Tom Lane authored
transformForUpdate does: it should recurse into subqueries.
-
Tom Lane authored
It could be recursing into a sub-query where there was already a FOR UPDATE clause.
-
- 06 Dec, 2000 4 commits
-
-
Tom Lane authored
work where we can (given that the executor only handles it at top level) and generate an error where we can't. Note that while the parser has been allowing views to say SELECT FOR UPDATE for a few weeks now, that hasn't actually worked until just now.
-
Marc G. Fournier authored
update VERSION to 7.1beta1..
-
Peter Eisentraut authored
through to here yet.
-
Tom Lane authored
the installed header file set.
-
- 05 Dec, 2000 5 commits
-
-
Tom Lane authored
an error at end of transaction ... and I did *not* like it. Reduce ERROR to NOTICE so that this situation doesn't cause an infinite loop.
-
Tom Lane authored
an error as we used to. In an OUTER JOIN scenario, retrieving a null CTID from one of the input relations is entirely expected. We still want to lock the input rows from the other relations, so just ignore the null and keep going.
-
Tom Lane authored
I believe this should fix the issue that Philip Warner noticed about the check for unique constraints meeting the referenced keys of a foreign key constraint allowing the specification of a subset of a foreign key instead of rejecting it. I also added tests for a base case of this to the foreign key and alter table tests and patches for expected output.
-
Tom Lane authored
-
Tom Lane authored
report from Joel Burton. Turns out that my simple idea of turning the SELECT into a subquery does not interact well *at all* with the way the rule rewriter works. Really what we need to make INSERT ... SELECT work cleanly is to decouple targetlists from rangetables: an INSERT ... SELECT wants to have two levels of targetlist but only one rangetable. No time for that for 7.1, however, so I've inserted some ugly hacks to make the rewriter know explicitly about the structure of INSERT ... SELECT queries. Ugh :-(
-
- 04 Dec, 2000 4 commits
- 03 Dec, 2000 12 commits
-
-
Peter Eisentraut authored
-
Tom Lane authored
values, whether the local char type is signed or not. This is necessary for portability. Per discussion on pghackers around 9/16/00.
-
Tom Lane authored
correct on the relevant platforms.
-
Tom Lane authored
-
Tom Lane authored
very unhappy ...
-
Peter Eisentraut authored
-
Thomas G. Lockhart authored
Allow some operator-like tokens to be used as function names. Flesh out support for time, timetz, and interval operators and interactions. Regression tests pass, but non-reference-platform horology test results will need to be updated.
-
Thomas G. Lockhart authored
-
Thomas G. Lockhart authored
-
Thomas G. Lockhart authored
-
Peter Eisentraut authored
-
Vadim B. Mikheev authored
critical sections of code.
-