return type, make protection condition agree with recent change to
pg_stat_get_backend_activity, clean up documentation.

find out about it is to read the documentation that tells you how
dangerous it is.  Add default_transaction_read_only to documentation;
seems to have been overlooked in patch that added read-only transactions.
Clean up check_guc comparison script, which has been suffering bit rot.

table.  Needed due to recent change that makes us call ExecutorStart
even when not planning to carry out the query.

config files are present on one pass and not present on a later pass.

cast-away-const warnings from compilers pickier than gcc.

of unnamed joins; per pghackers discussion 31-Mar-03.

< * Add --port flag to regression tests

remove useless SockAddr_ntop() call.  Per report from Andreas Pflug.

(ye good olde uninitialized-local-variable).

machines without IPv6.  Or at least it works on HPUX 10.20 ...

CHANGES

Mar 28, 2003
    Added finctions index(ltree,ltree,offset), text2ltree(text),
                    ltree2text(text)

Teodor Sigaev

and hasn't been called yet.

Fixes bug where it wasn't supplied (due to being NULL).

Rod Taylor

an unneeded memory context and some variables that are not used anymore.
It's pretty trivial and the regression tests pass fine.  There's no
change in functionality, only deletion of unused code.  I left an empty
function because maybe I'll need it for nested transactions.

Alvaro Herrera

harmless on signed-char machines but would lead to core dump in the
deadlock detection code if char is unsigned.  Amazingly, this bug has
been here since 7.1 and yet wasn't reported till now.  Thanks to Robert
Bruccoleri for providing the opportunity to track it down.

function if the OS doesn't provide one.

SSL_read/write can error needing ERROR_WANT_READ or ERROR_WANT_WRITE.

typing error in src/backend/libpq/be-secure.c ???

Long Description
In src/backend/libpq/be-secure.c: secure_write
on SSL_ERROR_WANT_WRITE call secure_read instead
secure_write again. May be is this a typing error?

Sergey N. Yatskevich (syatskevich@n21lab.gosniias.msk.ru)

page when it's read in, per pghackers discussion around 17-Feb.  Add a
GUC variable zero_damaged_pages that causes the response to be a WARNING
followed by zeroing the page, rather than the normal ERROR; this is per
Hiroshi's suggestion that there needs to be a way to get at the data
in the rest of the table.

bogus than it was.  Per bug report from Adrian Pop.

block, ala C++.

include output that vary depending on the python build one is
running. Basically, the order of keys in a dictionary is
non-deterministic, and that part of the test fails for me regularly.

I rewrote the test to work around this problem, and include a patch
file with that change and the change to the expected otuput as well.

Mike Meyer

Example:

test=# \d test
     Table "public.test"
 Column |  Type   | Modifiers
--------+---------+-----------
 a      | integer | not null
Indexes:
    "test_pkey" PRIMARY KEY btree (a)
Check Constraints:
    "$2" CHECK (a > 1)
Foreign Key Constraints:
    "$1" FOREIGN KEY (a) REFERENCES parent(b)
Rules:
    myrule AS ON INSERT TO test DO INSTEAD NOTHING
Triggers:
    "asdf asdf" AFTER INSERT OR DELETE ON test FOR EACH STATEMENT EXECUTE
PROCEDURE update_pg_pwd_and_pg_group(),
    mytrigger AFTER INSERT OR DELETE ON test FOR EACH ROW EXECUTE PROCEDURE
update_pg_pwd_and_pg_group()

I have minimised the double quoting of identifiers as much as I could
easily, and I will submit another patch when I have time to work on it that
will use a 'fmtId' function to determine it exactly.

I think it's a significant improvement in legibility...

Obviously the table example above is slightly degenerate in that not many
tables in production have heaps of (non-constraint) triggers and rules.

Christopher Kings-Lynne

(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