[PATCHES] RESET SESSION v3
Changes in v3: * DEALLOCATE PREPARE ALL * RESET PLANS wont check for ACL_CREATE_TEMP anymore. * Add prepare.h and portal.h to guc.c. On 4/7/07, Neil Conway [EMAIL PROTECTED] wrote: * RESET SESSION does not ABORT anymore, instead fails if in transaction. I think it's quite bizarre to have RESET SESSION fail if used in a transaction, but to allow an equivalent sequence of commands to be executed by hand inside a transaction. I think implicit ABORT would annoy various tools that partially parse user sql and expect to know what transaction state currently is. For them a new tranaction control statement would be nuisance. guc.c is missing some #includes. For some reason gcc4.0 did not show any warnings by default. * DEALLOCATE PREPARE ALL gives bison conflicts. Is that even needed? Seems best to have it, for the sake of consistency. The shift/reduce conflict is easy to workaround, provided you're content to duplicate the body of the DEALLOCATE ALL rule -- e.g. see the attached incremental diff. Thanks, included. * Are the CommandComplete changes needed? Seems warranted to me. BTW, why is CLOSE's command tag CLOSE CURSOR, not CLOSE? That seems needlessly verbose, and inconsistent with other commands (e.g. DEALLOCATE). Because the regular tag is CLOSE CURSOR. I did not want to break any expectations. But yes, the inconsistency is weird. * ResetPlanCache() is implemented as PlanCacheCallback((Datum)0, InvalidOid); That seems to leave plans for utility commands untouched. Is it problem? Yes, I'd think you'd also want to cleanup plans for utility commands. Tom thought otherwise, so I kept the old way. -- marko reset_session_v3.diff Description: Binary data ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] LIMIT/SORT optimization
On Sat, 2007-04-07 at 22:16 -0400, Bruce Momjian wrote: The patch is faster until we hit 100k or 10% of the table, at which point it is the same speed. What is interesting is 1M is also the same speed: All tests good, AFAICS. Thanks Bruce. Patch is operating as expected: the common case is considerably faster and the uncommon case isn't any slower. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Heap page diagnostic/test functions (v2)
On Sat, 2007-04-07 at 18:19 -0400, Bruce Momjian wrote: Simon Riggs wrote: On Sat, 2007-04-07 at 11:53 -0400, Bruce Momjian wrote: This looks useful, but shouldn't it be part of /contrib/pgstattuple rather than in the backend? Well, this was written with a view to it being usable for writing test cases that checked the various tuple states as we went. It was originally proposed when Tom asked How will we test HOT? (concurrent psql is the other half of the required base functionality to write sensible test cases). If we see it as a manual test tool only, contrib is OK. But it has to be in the backend to be usable in the regression test suite, so thats where it was designed to go. Well, contrib can have its own regression tests. We can put the HOT tests in there too. OK. I'll rework it once I've completed the other items on my list. Feel free to have a hack at it if I'm a little slow. I only have today left before I'm away for two weeks - travelling tomorrow. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Reviewers Guide to Deferred Transactions/TransactionGuarantee
On Thu, 2007-04-05 at 22:56 +0100, Simon Riggs wrote: transaction_guarantee.v11.patch correct files attached Open Questions -- 1. Should the DFC use a standard hash table? Custom code allows both additional speed and the ability to signal when it fills. 2. Should tqual.c update the LSN of a heap page with the LSN of the transaction commit that it can read from the DF cache? I now think we should update the LSN of the page, but not changed yet. 3. Should the WALWriter also do the wal_buffers half-full write at the start of XLogInsert() ? Not that important 4. The recent changes to remove CheckpointStartLock haven't changed the code path for deferred transactions, so a similar solution might be possible there also. Some further discussion required here, I think. That change may actually have introduced a slight risk into the patch. Will raise at review. 5. Is it correct to do WAL-before-flush for clog only, or should this be multixact also? Not necessary -- Simon Riggs EnterpriseDB http://www.enterprisedb.com tg.tar.gz Description: application/compressed-tar ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Reviewers Guide to Deferred Transactions/TransactionGuarantee
Simon Riggs [EMAIL PROTECTED] writes: 4. The recent changes to remove CheckpointStartLock haven't changed the code path for deferred transactions, so a similar solution might be possible there also. Some further discussion required here, I think. That change may actually have introduced a slight risk into the patch. Will raise at review. Given that you're going to be gone for the next two weeks, I'm wondering when you think that discussion will happen. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Reviewers Guide to DeferredTransactions/TransactionGuarantee
On Sun, 2007-04-08 at 11:05 -0400, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: 4. The recent changes to remove CheckpointStartLock haven't changed the code path for deferred transactions, so a similar solution might be possible there also. Some further discussion required here, I think. That change may actually have introduced a slight risk into the patch. Will raise at review. Given that you're going to be gone for the next two weeks, I'm wondering when you think that discussion will happen. Well, now is good... but I would never say this must happen now. I'm sorry my schedule is busy at this time, I really thought the change of dates would mean I'd avoid my normal disappearing trick. Previously its been family holidays, now its just other business I am called to. My concern was this: If we flush the currently outstanding deferred transactions then that doesn't guarantee they have all reached the clog. Previously, a deferred transaction would not release the CheckpointStartLock until after the clog had been updated. If we wait for all currently inCommit transactions to end this will cover all deferred transactions also. So I think I just need to flush deferred transactions prior to the wait and this will be valid. Would you agree? -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] xpath_array with namespaces support
I've realized that Peter's criticism (concerning comparing beginning of datum with ?xml) is right: current approach is unable to work with XML values such as ?xml ...?a /b /. I'll propose a modification of the patch as long as fixes for NULLs as input and output values very soon (in a day or so). On 4/4/07, Nikolay Samokhvalov [EMAIL PROTECTED] wrote: The patch attached contains following changes: 1. The function name xmlpath() is changed to xpath(); 2. Approach of passing of namepspace mappings to the function is changed: now that array (the 3rd argument) should be a 2-dimentional array with the length of the second axis = 2 (e.g., ARRAY[ARRAY['a1', 'http://a1'], ARRAY['a2', 'http://a2'], ARRAY['a2', 'http://a2']]); 3. Description of xpath() function in docs (I'm sorry for possible mistakes in English and docbook formatting, please check it...) On 4/3/07, Bruce Momjian [EMAIL PROTECTED] wrote: Nikolay Samokhvalov wrote: On 3/22/07, Peter Eisentraut [EMAIL PROTECTED] wrote: Bruce Momjian wrote: Patch applied. This code seems to think that if an xml datum starts with ?xml it's a document. That is completely bogus. Agreed. I'll fix it. Nikolay, it has been a week, and I have see no fixes from you in response to requests from Peter. If the patch doesn't arrive in 1-2 days, I will have to revert your patch and it will be kept for 8.4. Feature freeze was April 1, 2007. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Best regards, Nikolay -- Best regards, Nikolay ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [DOCS] Fix misleading references to columns in GRANT/REVOKE summaries
Tom Lane wrote: True, there doesn't seem to be any point in providing a full syntax summary rather than just saying the SQL spec says you can grant privileges on columns but we don't support that yet. I think it's pretty useful if people see a command of this form from some other implementation and don't know what it means. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [DOCS] Fix misleading references to columns in GRANT/REVOKE summaries
Bruce Momjian wrote: True, there doesn't seem to be any point in providing a full syntax summary rather than just saying the SQL spec says you can grant privileges on columns but we don't support that yet. Agreed. Patch attached and applied. I don't see any other cases of this in our documentation. That doesn't mean this one isn't useful. Please revert this. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Correct the spelling of SYMMETRIC
Bruce Momjian wrote: Michael Fuhr wrote: On Fri, Apr 06, 2007 at 11:34:39PM -0400, Bruce Momjian wrote: Patch applied. Thanks. Your documentation changes can be viewed in five minutes using links on the developer's page, Thanks. 8.1 and 8.2 have the same typo -- any reason not to backpatch this? OK, fixed in 8.2.X. We don't patch documentation past the most recent major release. Why not? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[PATCHES] Minor recovery changes
As discussed on -hackers and -admin... a few minor changes, rolled into a single patch. - check we have an archiver to carry away WAL files at shutdown (was part of task 1) - archive_mode GUC, on which archive_command is dependent closing loophole to avoid data loss with wal-avoiding commands (was task 10) - %r option in recovery.conf sends last restartpoint to recovery command (was task 3) - %r handled in pg_standby, updated README (was task 4) - code cleanup of pg_standby in various minor places - doc on Warm Standby now includes pg_standby and %r - log_restartpoints shows LOG message for at each restartpoint, rather than DEBUG2 e.g. LOG: recovery restart point at 0/4220 (was task 5) - end of recovery now displays last transaction end time, as requested by Warren Little e.g. LOG: last completed transaction was at log time 2007-04-08 18:07:11 BST also shown at each restartpoint (discussed on -admin, mar 30) TODO (by me) - docs need another thorough refresh to pick up minor mentions of archive_command - archive_mode - work out how to keep archiver alive long enough to archive last WAL file after a shutdown checkpoint... trickier than I imagined since it overlaps need for fast exit when performing restart, per last edit of the archiver code. - agree whether to allow pg_stop_backup() to exit before file archived Applies cleanly to CVS HEAD. Updated test files, all options tested. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com test_warm_standby.tar.gz Description: application/compressed-tar recovery_cleanup.v1.patch.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] Arrays of Complex Types
Tom Lane wrote: David Fetter [EMAIL PROTECTED] writes: On Mon, Apr 02, 2007 at 10:01:44PM -0400, Alvaro Herrera wrote: So, hum, what happened to the idea of creating the array types only on demand? Scotched, as far as I could tell, More like you submitted a patch that entirely ignores multiple people's opinion on what is needed. Bruce may have put this into the patch queue, but do not labor under the delusion that that means it'll get applied as-is. The queue is currently operating as a list of open issues. One of the things that's been bothering me about this proposal is that it leaves untouched and indeed greatly expands the scope of the typename mangling we do. (i.e. adding an entry to pg_type with _ prepended). Up to now we've only used this gadget in a way that might matter a lot on user defined non-composite types, I think, and now we have expanded that to include enums, which are really a special case of user defined non-composites which don't require an extra C module. That's a comparatively small window, but this proposal will extend it to all composites, which is quite a large expansion in scope. And since _ is a perfectly legal initial char for an identifier, if type _foo exists then any attempt to create a table or view or composite called foo will fail. Is it possible to fix this, or am I trying to shut the stable door after the horse has well and truly bolted? If it can be fixed, I'd like to see it fixed before we fix the problem David is trying to address here. It's been suggested to me that this is an insignificant corner case. But I have often seen coding standards that actually require certain classes of identifier to being with _, so it's very far from a merely theoretical point. I'm slightly inclined to agree with David that the danger of catalog bloat isn't that great, and might not justify the extra work that some sort of explicit array creation would involve (e.g. changes in grammar, pg_dump), as long as we are agreed that we don't want array types ever to have their own user definable names or settable namespace. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] Arrays of Complex Types
Andrew Dunstan [EMAIL PROTECTED] writes: One of the things that's been bothering me about this proposal is that it leaves untouched and indeed greatly expands the scope of the typename mangling we do. (i.e. adding an entry to pg_type with _ prepended). Yeah, that's been bothering me too. One of the problems with the patch as-is is that it extends the 62-instead-of-63-char limit to table names as well as type names. I've been thinking of proposing that we add a column to pg_type that points from a type to its array type (if any), ie the reverse link from typelem. If we had that then the parser could follow that to determine which type is foo[], instead of relying on the _foo naming convention. I don't suggest that we stop using the naming convention, but it would no longer be a hard-and-fast rule, just a convention. In particular we could rejigger things around the edges to reduce the name conflict problem. For instance the rule for forming array type names could be prepend _, truncate to less than 64 bytes if necessary, then substitute numbers at the end if needed to get something unique. This is not all that different from what we do now to get unique serial sequence names, for example. This would also open the door to supporting CREATE TYPE foo AS ARRAY OF bar without having to have any restrictions about the name of foo. I'd still much rather do things that way for arrays of composites than invent a ton of pg_type entries that are mostly going to go unused. regards, tom lane PS: Has anyone looked at what it will take to make the entries in an array-of-composite be something smaller than full tuples? It's not going to be anything but a toy unless you can get the per-entry overhead down to something sane. Perhaps the MinimalTuple representation would work. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Arrays of Complex Types
On Sun, Apr 08, 2007 at 07:08:38PM -0400, Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: One of the things that's been bothering me about this proposal is that it leaves untouched and indeed greatly expands the scope of the typename mangling we do. (i.e. adding an entry to pg_type with _ prepended). Yeah, that's been bothering me too. One of the problems with the patch as-is is that it extends the 62-instead-of-63-char limit to table names as well as type names. I did this by copying some code which already creates array names, so should that code change to do something different, the 62-instead-of-63-char thing would go away along with it. I agree that the prepended _s are far from optimal. I've been thinking of proposing that we add a column to pg_type that points from a type to its array type (if any), ie the reverse link from typelem. If we had that then the parser could follow that to determine which type is foo[], instead of relying on the _foo naming convention. I don't suggest that we stop using the naming convention, but it would no longer be a hard-and-fast rule, just a convention. That'd be neat :) In particular we could rejigger things around the edges to reduce the name conflict problem. For instance the rule for forming array type names could be prepend _, truncate to less than 64 bytes if necessary, then substitute numbers at the end if needed to get something unique. This is not all that different from what we do now to get unique serial sequence names, for example. This would also open the door to supporting CREATE TYPE foo AS ARRAY OF bar I'm sorry to keep harping on this, but I really don't see a use case and do see foot guns both with making the array types optional and with decoupling their names from those of their respective compound types. When they're optional, we get all kinds of stepping on a step that isn't there issues, and when they're decoupled, operations like, ALTER TABLE foo RENAME TO bar have either surprising or undefined behavior, or both. without having to have any restrictions about the name of foo. I'd still much rather do things that way for arrays of composites than invent a ton of pg_type entries that are mostly going to go unused. I'm sure there's a better way than my first attempt. PS: Has anyone looked at what it will take to make the entries in an array-of-composite be something smaller than full tuples? It's not going to be anything but a toy unless you can get the per-entry overhead down to something sane. Perhaps the MinimalTuple representation would work. Sounds neat, too :) Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! Consider donating to PostgreSQL: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] Arrays of Complex Types
Tom Lane wrote: I've been thinking of proposing that we add a column to pg_type that points from a type to its array type (if any), ie the reverse link from typelem. If we had that then the parser could follow that to determine which type is foo[], instead of relying on the _foo naming convention. good. I don't suggest that we stop using the naming convention, but it would no longer be a hard-and-fast rule, just a convention. In particular we could rejigger things around the edges to reduce the name conflict problem. For instance the rule for forming array type names could be prepend _, truncate to less than 64 bytes if necessary, then substitute numbers at the end if needed to get something unique. This is not all that different from what we do now to get unique serial sequence names, for example. Sounds OK but I'd add something that might make it even more unlikely to generate a name clash. This would also open the door to supporting CREATE TYPE foo AS ARRAY OF bar without having to have any restrictions about the name of foo. I'd still much rather do things that way for arrays of composites than invent a ton of pg_type entries that are mostly going to go unused. ISTM we should either do it all automatically or all manually. If you want user defined names for array types then we can forget name mangling for user defined types and do everything manually. cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [HACKERS] Arrays of Complex Types
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: I don't suggest that we stop using the naming convention, but it would no longer be a hard-and-fast rule, just a convention. In particular we could rejigger things around the edges to reduce the name conflict problem. For instance the rule for forming array type names could be prepend _, truncate to less than 64 bytes if necessary, then substitute numbers at the end if needed to get something unique. This is not all that different from what we do now to get unique serial sequence names, for example. Sounds OK but I'd add something that might make it even more unlikely to generate a name clash. Like what? I don't want to stray far from _foo when we don't have to, because I'm sure there is user code out there that'll still rely on that naming convention; we shouldn't break it if we don't have to. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Arrays of Complex Types
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: I don't suggest that we stop using the naming convention, but it would no longer be a hard-and-fast rule, just a convention. In particular we could rejigger things around the edges to reduce the name conflict problem. For instance the rule for forming array type names could be prepend _, truncate to less than 64 bytes if necessary, then substitute numbers at the end if needed to get something unique. This is not all that different from what we do now to get unique serial sequence names, for example. Sounds OK but I'd add something that might make it even more unlikely to generate a name clash. Like what? I don't want to stray far from _foo when we don't have to, because I'm sure there is user code out there that'll still rely on that naming convention; we shouldn't break it if we don't have to. Oh, in that case maybe we'd better live with it :-( I certainly think we should deprecate relying on it. cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [HACKERS] Arrays of Complex Types
Andrew Dunstan [EMAIL PROTECTED] writes:
I'm slightly inclined to agree with David that the danger of catalog
bloat isn't that great, and might not justify the extra work that some
sort of explicit array creation would involve (e.g. changes in grammar,
pg_dump), as long as we are agreed that we don't want array types ever
to have their own user definable names or settable namespace.
I did some tests just now to determine the total number of catalog
entries associated with a simple table definition. Assuming it has
N user columns of built-in types (hence not requiring pg_depend entries
for the datatypes), I count
1 pg_class entry for the table itself
1 pg_type entry for the rowtype
N + 6 pg_attribute entries for the user and system columns
2 pg_depend entries (type - table and table - namespace)
2 pg_shdepend entries (ownership of table and type)
Of course this goes up *fast* if you need a toast table, indexes,
constraints, etc, but that's the irreducible minimum.
Generating an array rowtype would add three more catalog entries to this
(the array pg_type entry, a pg_depend arraytype-rowtype link, and
another pg_shdepend entry), which isn't a huge percentage overhead.
Obviously if we wanted to trim some fat here, getting rid of the
redundant pg_attribute entries for system columns would be the first
place to look.
Based on this, I withdraw my efficiency concern about generating
rowtypes for all user tables. I do, however, still object to generating
them for system tables. In particular an array type for pg_statistic
will actively Not Work and probably constitute a security hole, because
of the anyarray hack we use there.
BTW, I just noticed that we currently create array types with AUTO
dependencies on their element type, meaning that you can drop them
separately:
regression=# create type fooey as enum ('a','b');
CREATE TYPE
regression=# drop type _fooey;
DROP TYPE
Is this a bad idea? If we made the dependency INTERNAL then the
system would refuse the drop above. I think we would have to do
that if we wanted to add the base-array link I suggested, because
otherwise this drop would leave a dangling pointer in pg_type.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [DOCS] Fix misleading references to columns in GRANT/REVOKE summaries
Peter Eisentraut wrote: Bruce Momjian wrote: True, there doesn't seem to be any point in providing a full syntax summary rather than just saying the SQL spec says you can grant privileges on columns but we don't support that yet. Agreed. Patch attached and applied. I don't see any other cases of this in our documentation. That doesn't mean this one isn't useful. Please revert this. Well, Tom and I thought it caused confusion, as did the person reporting the confusion. You saying to revert it isn't enough. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Arrays of Complex Types
Tom Lane wrote: Based on this, I withdraw my efficiency concern about generating rowtypes for all user tables. I do, however, still object to generating them for system tables. In particular an array type for pg_statistic will actively Not Work and probably constitute a security hole, because of the anyarray hack we use there. How would we do that? Not create the array types in bootstrap mode? Or just special-case pg_statistic? cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] Arrays of Complex Types
Andrew Dunstan [EMAIL PROTECTED] writes: How would we do that? Not create the array types in bootstrap mode? Or just special-case pg_statistic? Not generate them in bootstrap mode works for me. IIRC, there's code somewhere in there that allows anyarray to pass as a column type in bootstrap mode, so that seems to fit ... regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [DOCS] Fix misleading references to columns in GRANT/REVOKE summaries
Bruce Momjian [EMAIL PROTECTED] writes: Peter Eisentraut wrote: That doesn't mean this one isn't useful. Please revert this. Well, Tom and I thought it caused confusion, as did the person reporting the confusion. You saying to revert it isn't enough. A possible compromise is to describe or show the syntax in some informal form, so that it didn't look like one of the synopsis sections we use for supported syntax. I'm not sure what that would look like exactly, but I do see merit in both sides of this discussion... regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] UTF8MatchText
Bruce Momjian [EMAIL PROTECTED] wrote:
I do not understand this patch. You have defined two functions,
UTF8MatchText() and UTF8MatchTextIC(), and the difference between them
is that one calls CHAREQ and the other calls ICHAREQ, but just above
those two functions you define the macros identically:
Why are there two functions? Also, can't you use one function and just
pass a boolean to indicate whether case should be ignored?
The same is true of MBMatchText() and MBMatchTextIC().
Now, I'll split the patch into two changes.
1. DropMBMatchTextIC.patch
Drop MBMatchTextIC() and use MBMatchText() instead.
2. UTF8MatchText.patch
Add UTF8MatchText() as a specialized version of MBMatchText().
As a future work, it might be good to research the performance of rewriting
col ILIKE 'pattern' to lower(col) LIKE lower('pattern') in planner so that
we can avoid to call lower() for constant pattern in the right-hand side and
can use functional indexes (lower(col)). I think we never need MBMatchTextIC()
in the future unless we move to wide-character server encoding :)
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
DropMBMatchTextIC.patch
Description: Binary data
UTF8MatchText.patch
Description: Binary data
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [PATCHES] [DOCS] Fix misleading references to columns in GRANT/REVOKE summaries
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Peter Eisentraut wrote: That doesn't mean this one isn't useful. Please revert this. Well, Tom and I thought it caused confusion, as did the person reporting the confusion. You saying to revert it isn't enough. A possible compromise is to describe or show the syntax in some informal form, so that it didn't look like one of the synopsis sections we use for supported syntax. I'm not sure what that would look like exactly, but I do see merit in both sides of this discussion... I am all for us describing how we don't match the SQL spec, but just showing the syntax doesn't seem to help people understand how we don't match the spec, does it? Are there more details to column-level GRANT except saying we don't support it? -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Minor recovery changes
Simon, do you have email access while you are away for two weeks? Can you answer questions via email? --- Simon Riggs wrote: As discussed on -hackers and -admin... a few minor changes, rolled into a single patch. - check we have an archiver to carry away WAL files at shutdown (was part of task 1) - archive_mode GUC, on which archive_command is dependent closing loophole to avoid data loss with wal-avoiding commands (was task 10) - %r option in recovery.conf sends last restartpoint to recovery command (was task 3) - %r handled in pg_standby, updated README (was task 4) - code cleanup of pg_standby in various minor places - doc on Warm Standby now includes pg_standby and %r - log_restartpoints shows LOG message for at each restartpoint, rather than DEBUG2 e.g. LOG: recovery restart point at 0/4220 (was task 5) - end of recovery now displays last transaction end time, as requested by Warren Little e.g. LOG: last completed transaction was at log time 2007-04-08 18:07:11 BST also shown at each restartpoint (discussed on -admin, mar 30) TODO (by me) - docs need another thorough refresh to pick up minor mentions of archive_command - archive_mode - work out how to keep archiver alive long enough to archive last WAL file after a shutdown checkpoint... trickier than I imagined since it overlaps need for fast exit when performing restart, per last edit of the archiver code. - agree whether to allow pg_stop_backup() to exit before file archived Applies cleanly to CVS HEAD. Updated test files, all options tested. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com [ Attachment, skipping... ] [ Attachment, skipping... ] ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
