[DOCS] Docs on PREPARE sql command should probably point to DEALLOCATE ...
In reading the 7.4.2 docs, the sql reference page for PREPARE doesn't reference DEALLOCATE in any way. It points to EXECUTE, but not to DEALLOCATE. Suggested fix: ... This also means that a single prepared statement cannot be used by multiple simultaneous database clients; however, each client can create their own prepared statement to use. The prepared statement can be manually cleaned up using the DEALLOCATE command. James Robinson Socialserve.com ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] [HACKERS] bug in GUC
On Jun 24, 2004, at 10:45 AM, Thomas Hallgren wrote: So, what you are saying is that there's no need for the functions I suggested and that a palloc using the TopMemoryContext will guarantee correct behavior on "out of memory"? Perhaps a section regarding proper memory management code in the backend could be written , say, somewhere in the internals document around the coding conventions chapter: http://developer.postgresql.org/docs/postgres/source.html I myself don't have a clue, not being a backend hacker, so I'll just slink back to my cave. James Robinson Socialserve.com ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[DOCS] create index concurrently docs ...
In reading over the caveats regarding create index concurrently, I think it'd be nice to see an example of what the return result will be if an 'invalid' index is created so a dba who read the docs night recognize the error, as well as for searchengine fodder to find out what to do real fast if such an error happens to them. Something around this paragraph in http://www.postgresql.org/docs/ current/static/sql-createindex.html#SQL-CREATEINDEX-CONCURRENTLY: "If a problem arises during the second scan of the table, such as a uniqueness violation in a unique index, the CREATE INDEX command will fail but leave behind an "invalid" index." Thanks! James Robinson Socialserve.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[DOCS] psqlODBC homepage bad link on http://www.postgresql.org/docs/8.2/static/external-interfaces.html
http://odbc.postgresql.org/ no longer exists? James Robinson Socialserve.com -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] plpgsql, declare blocks, and '=' versus ':='
It seems that [ in 8.2.9 at least ], in a plpgsql declare block, assignment to declared variable can use either the proper ':=' operator or the unexpected and undocumented '=' operator. See following script. The magic handling of '=' ought to get documented at least. [ plpgsql-declarations.html makes no mention of '=' token handling in either 8.3 or 8.2. docs ] --- create or replace function test_1() returns int as $$ declare value int = 12; -- wow -- no colon! begin return value; end; $$ language plpgsql; create or replace function test_2() returns int as $$ declare value int := 14; -- correct begin return value; end; $$ language plpgsql; select test_1(); -- returns 12 select test_2(); -- returns 14 - James Robinson Socialserve.com -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
