Re: [HACKERS] WIP: Automatic view update rules
--On Samstag, Januar 17, 2009 02:01:15 +0200 Peter Eisentraut pete...@gmx.net wrote: * It is not clear how automatic rules and manual DO ALSO rules should interact. A manual DO ALSO rule will currently clear out an automatic INSTEAD rule, which I find to be illogical. My intentional feeling was that it would be a bad idea to leave any implicit rule when someone is going to create his own rule set on a view, at least to avoid any confusion or side effects. Consider someone having his own rules upgrading from an older version. He must have at least his own DO INSTEAD Rule, it doesn't make any sense to have his own DO ALSO Rule without an INSTEAD one. Thus, doing it this way will leave the view as expected from the original setup. *thinking more*...if we teach explicit DO ALSO rules *not* to clean out implicit ones, we will have the following workflows: a) View is updatable, has its own automatic DO INSTEAD rule: if someone is restoring his old update rules, he will have at least his own DO INSTEAD rule. This will drop any corresponding automatically created rule, adding his own DO INSTEAD rule and any DO ALSO rule. b) View is updatable, has its own automatic DO INSTEAD rule: The user is able to create any additional DO ALSO rule. I don't see any problems here, as long as the implicit DO INSTEAD rule gets replaced. Opinions? -- Thanks Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] libpq WSACleanup is not needed
James Mansion wrote: Andrew Chernow wrote: m$ docs indicate that wsastartup can't be called from dllmain :( OK, fair cop. Says it in the MSDN online version but not in the SDK 6.1 version. :-( Some helper(s) must start threads I guess. That, and it loads other DLLs as well. Re the counting and doing it on first/last socket - of course WSAStartup counts internally. Prsumably its only slow when the count is actually going to zero? Yes. Is there a need for a new API to control this - can't you just interpret another parameter keyword in PQconnectdb (or the pgoptions string in PQsetdbLogin I guess)? (Having said that, how do you control send and receive buffer sizes? Presumably nagle is always disabled, but those features could be controlled the same way? Would presumably allow PGOPTIONS to be parsed too, though docs 30.12 says that does runtime options for the server, though PQconnectdb in 30.1 suggests that it might be parsed for the client connect too. Maybe.). You can always get the socket descriptor back and modify it directly, if you are sure that what you're changing is supported.. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: Automatic view update rules
Bernd Helmle wrote: --On Samstag, Januar 17, 2009 02:01:15 +0200 Peter Eisentraut pete...@gmx.net wrote: * It is not clear how automatic rules and manual DO ALSO rules should interact. A manual DO ALSO rule will currently clear out an automatic INSTEAD rule, which I find to be illogical. My intentional feeling was that it would be a bad idea to leave any implicit rule when someone is going to create his own rule set on a view, at least to avoid any confusion or side effects. Consider someone having his own rules upgrading from an older version. He must have at least his own DO INSTEAD Rule, it doesn't make any sense to have his own DO ALSO Rule without an INSTEAD one. Thus, doing it this way will leave the view as expected from the original setup. *thinking more*...if we teach explicit DO ALSO rules *not* to clean out implicit ones, we will have the following workflows: a) View is updatable, has its own automatic DO INSTEAD rule: if someone is restoring his old update rules, he will have at least his own DO INSTEAD rule. This will drop any corresponding automatically created rule, adding his own DO INSTEAD rule and any DO ALSO rule. b) View is updatable, has its own automatic DO INSTEAD rule: The user is able to create any additional DO ALSO rule. I don't see any problems here, as long as the implicit DO INSTEAD rule gets replaced. Someone who previously had a DO INSTEAD rule to effect updatable views as well as a DO ALSO rule to create some side effect (e.g., auditing/logging), will after the upgrade perhaps want to rely on the automatic view update rules but will still want to create his own DO ALSO rule. In the current patch, the creation of the DO ALSO rule will delete the automatic view update rules, thus breaking the entire scenario. Considering that the updatable views feature deals only with DO INSTEAD rules, we should leave DO ALSO rules completely alone. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby dev build (v8)
On Mon, 2009-01-19 at 09:16 +0200, Heikki Linnakangas wrote: Simon Riggs wrote: On Fri, 2009-01-16 at 22:09 +0200, Heikki Linnakangas wrote: RecentGlobalXmin is just a hint, it lags behind the real oldest xmin that GetOldestXmin() would return. If another backend has a more recent RecentGlobalXmin value, and has killed more recent tuples on the page, the latestRemovedXid written here is too old. What do you think we should do instead? Dunno. Maybe call GetOldestXmin(). We are discussing btree deletes, not btree vacuums. Pardon my ignorance, but what's the difference? In terms of current HEAD, not much. In terms of Hot Standby, a significant difference - the two actions have been split, rather than continuing to share the same WAL record. XLOG_BTREE_VACUUM removes index tuples as a result of a vacuum. The initial scan of the heap already generated an XLOG_HEAP2_CLEANUP_INFO which gives the latestRemovedXid for that vacuum. So we don't need to worry about putting a latestRemovedXid on XLOG_BTREE_VACUUM. The WAL records also differ because the XLOG_BTREE_VACUUM contains details of blocks that need to be pinned but not otherwise touched. XLOG_BTREE_DELETE is different in 3 ways. It isn't part of a vacuum, so: * we don't need to take a cleanup lock * it doesn't contain info about other blocks we need to scan beforehand for correctness purposes * it wasn't preceded by an XLOG_HEAP2_CLEANUP_INFO record, so it must have a *correct* (even if too conservative) value for latestRemovedXid set. So the only time we need to set latestRemovedXid correctly is during a normal transaction, not during a vacuum. If we are doing btree delete then we have an unreleased snapshot therefore we also have a non-zero xmin. How can another backend have a later RecentGlobalXmin or result from GetOldestXmin() than we do? Sure it can, for example: 1. Transaction 1 begins in backend A 2. Transaction 2 begins in backend B, xmin = 1 3. Transaction 1 ends 4. Transaction 3 begins in backend C, xmin = 2 5. Backend C gets snapshot, TransactionXmin = 2, RecentGlobalXmin = 1 6. Transaction 2 ends. 7. Transaction 4 begins in backend A, gets snapshot TransactionXmin = 2, RecentGlobalXmin = 2 8. Transaction 4 kills tuple, using its RecentGlobalxmin of 1 9. Transaciont 3 splits the page, emits a delete xlog record, setting latestRemovedXid to its RecentGlobalXmin of 2 Well, steps 7 and 8 don't make sense. Your earlier comment was that it was possible for a WAL record to be written with a RecentGlobalXmin that was lower than other backends values. In step 9 the RecentGlobalXmin is *not* lower than any other backend, it is the same. So if there is a proof, this isn't it. But I can't see how there can be one: Two concurrent vacuums can have different OldestXmin values, but two concurrent transactions cannot. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby dev build (v8)
On Mon, 2009-01-19 at 12:22 +0200, Heikki Linnakangas wrote: Simon Riggs wrote: Well, steps 7 and 8 don't make sense. Your earlier comment was that it was possible for a WAL record to be written with a RecentGlobalXmin that was lower than other backends values. In step 9 the RecentGlobalXmin is *not* lower than any other backend, it is the same. So if there is a proof, this isn't it. Yeah, you're right. I got steps 8 and 9 mixed. Let me try again: 1. Transaction 1 begins in backend A 2. Transaction 2 begins in backend B, xmin = 1 3. Transaction 1 ends 4. Transaction 3 begins in backend C, xmin = 2 5. Backend C gets snapshot, TransactionXmin = 2, RecentGlobalXmin = 1 6. Transaction 2 ends. 7. Transaction 4 begins in backend A, gets snapshot TransactionXmin = 2, RecentGlobalXmin = 2 8. Transaction 3 kills tuple, using its RecentGlobalxmin of 2 9. Transaction 4 splits the page, emits a delete xlog record, setting latestRemovedXid to its RecentGlobalXmin of 1 One of us needs a coffee. How does Transaction 4 have a RecentGlobalXmin of 2 in step (7), but at step (9) the value of RecentGlobalXmin has gone backwards? -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby dev build (v8)
Simon Riggs wrote: One of us needs a coffee. Clearly, I put the kettle on... How does Transaction 4 have a RecentGlobalXmin of 2 in step (7), but at step (9) the value of RecentGlobalXmin has gone backwards? Looks like I mixed up the xids of the two transactions in steps 8 and 9. Let's see if I got it right this time: 1. Transaction 1 begins in backend A 2. Transaction 2 begins in backend B, xmin = 1 3. Transaction 1 ends 4. Transaction 3 begins in backend C, xmin = 2 5. Backend C gets snapshot, TransactionXmin = 2, RecentGlobalXmin = 1 6. Transaction 2 ends. 7. Transaction 4 begins in backend A, gets snapshot TransactionXmin = 2, RecentGlobalXmin = 2 8. Transaction 4 kills tuple, using its RecentGlobalxmin of 2 9. Transaction 3 splits the page, emits a delete xlog record, setting latestRemovedXid to its RecentGlobalXmin of 1 -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby dev build (v8)
On Mon, 2009-01-19 at 12:50 +0200, Heikki Linnakangas wrote: Simon Riggs wrote: One of us needs a coffee. Clearly, I put the kettle on... I had one too, just in case. How does Transaction 4 have a RecentGlobalXmin of 2 in step (7), but at step (9) the value of RecentGlobalXmin has gone backwards? Looks like I mixed up the xids of the two transactions in steps 8 and 9. Let's see if I got it right this time: 1. Transaction 1 begins in backend A 2. Transaction 2 begins in backend B, xmin = 1 3. Transaction 1 ends 4. Transaction 3 begins in backend C, xmin = 2 5. Backend C gets snapshot, TransactionXmin = 2, RecentGlobalXmin = 1 6. Transaction 2 ends. 7. Transaction 4 begins in backend A, gets snapshot TransactionXmin = 2, RecentGlobalXmin = 2 8. Transaction 4 kills tuple, using its RecentGlobalxmin of 2 9. Transaction 3 splits the page, emits a delete xlog record, setting latestRemovedXid to its RecentGlobalXmin of 1 I don't see how step (5) is possible. GetSnapshotData() sets RecentGlobalXmin to the result of the snapshot's xmin. If step (5) is possible, then yes, step (9) can happen. You are correct to say that RecentGlobalXmin is not always correctly set. All I'm saying is that at the exact time, place and circumstance I use it, it is correct. In other cases, it may not be. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] FATAL: could not open relation pg_tblspc/491086/467369/491103: No such file or directory
On Fri, 2009-01-16 at 19:12 +0100, Gianni Ciolli wrote: On Fri, Jan 16, 2009 at 06:39:11PM +0100, Gianni Ciolli wrote: (...) During a Warm Standby session using current HEAD I obtained the following error on the standby node: I think I understand the cause of these bugs in CVS HEAD now. In various places in current HEAD we throw a checkpoint when we want to be certain that all buffers have been flushed. In recovery, a checkpoint isn't always a restartpoint for two reasons: timing and rmgr state. This gives both a cause for the error and an explanation of why it does not occur consistently. ISTM this could likely effect previous releases as well. We need to put some marker into WAL to allow the same actions to be repeated in recovery. We can't just force these correctness checkpoints to be restartpoints because they might be invalid, but we can force CheckPointGuts() (or something less) without updating the control file. With regard to various changes I have in motion, the CheckPointGuts() would need to be executed in full before further WAL replay occurs, so would need to be executed by the Startup process and not by the bgwriter to ensure we performed the correct sequence of actions. CHECKPOINT_FORCE might be the right indicator of when to do take special action in recovery, not sure. Will look at this again later. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby dev build (v8)
Simon Riggs wrote: Well, steps 7 and 8 don't make sense. Your earlier comment was that it was possible for a WAL record to be written with a RecentGlobalXmin that was lower than other backends values. In step 9 the RecentGlobalXmin is *not* lower than any other backend, it is the same. So if there is a proof, this isn't it. Yeah, you're right. I got steps 8 and 9 mixed. Let me try again: 1. Transaction 1 begins in backend A 2. Transaction 2 begins in backend B, xmin = 1 3. Transaction 1 ends 4. Transaction 3 begins in backend C, xmin = 2 5. Backend C gets snapshot, TransactionXmin = 2, RecentGlobalXmin = 1 6. Transaction 2 ends. 7. Transaction 4 begins in backend A, gets snapshot TransactionXmin = 2, RecentGlobalXmin = 2 8. Transaction 3 kills tuple, using its RecentGlobalxmin of 2 9. Transaction 4 splits the page, emits a delete xlog record, setting latestRemovedXid to its RecentGlobalXmin of 1 But I can't see how there can be one: Two concurrent vacuums can have different OldestXmin values, but two concurrent transactions cannot. Of course they can. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby dev build (v8)
Simon Riggs wrote: GetSnapshotData() sets RecentGlobalXmin to the result of the snapshot's xmin. No. RecentGlobalXmin is set to the oldest *xmin* observed, across all running transactions. TransactionXmin is the xid of the oldest running transaction. IOW, RecentGlobalXmin is the xid of transaction that the oldest running transaction sees as running. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Fixes for compiler warnings
Tom Lane wrote: Magnus, you wanna clean up the mess? And what patch does the few more comment refer back to? A workable solution that both silences the warning and preserves localizability is to follow a coding pattern like this: const char *mymsg = gettext_noop(Some text to be localized.); ... errmsg(%s, _(mymsg)) // not just errmsg(mymsg) For a change like http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.480r2=1.481 Will it work to stick _(hintmsg) around it there? //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby dev build (v8)
On Mon, 2009-01-19 at 14:00 +0200, Heikki Linnakangas wrote: Simon Riggs wrote: GetSnapshotData() sets RecentGlobalXmin to the result of the snapshot's xmin. No. RecentGlobalXmin is set to the oldest *xmin* observed, across all running transactions. TransactionXmin is the xid of the oldest running transaction. IOW, RecentGlobalXmin is the xid of transaction that the oldest running transaction sees as running. OK. That was fun. These WAL records are annoying, no matter what the exact value of latestRemovedXid is and they seem likely to conflict with many queries on the standby. If we don't use RecentGlobalXmin then I can't see any easily derived value that we can use in its place. It isn't worth the effort on the master to derive a more exact value, not when we don't even know if it matters yet. I suggest we handle this on the recovery side, not on the master, by deriving the xmin at the point the WAL record arrives. We would calculate it by looking at recovery procs only. That will likely give us a later value than we would get from the master, but that can't be helped. For me, this makes it essential now that I put in place the deferred cancellation mechanism. Some refactoring in this area is also required because we need to handle two other types of conflict to correctly support drop database and drop user, which is now underway. Btree deletes were an important optimisation when it first went it, but now we have HOT it is much less important. Another route might be to put an option to turn off btree delete on the master, default = on. We probably should consider turning it off entirely when it doesn't yield significant benefit. Lots of scanning to remove the odd row is probably pretty wasteful and likely adds contention at the very point we don't want it - index splits. Thoughts? -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] libpq WSACleanup is not needed
James Mansion wrote: Is there a need for a new API to control this - can't you just interpret another parameter keyword in PQconnectdb (or the pgoptions string in PQsetdbLogin I guess)? That's an interesting idea. I don't know if its the correct place to control this, but it does allow turning off wsastartup and indicating which winsock version to load. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby dev build (v8)
Simon Riggs wrote: I suggest we handle this on the recovery side, not on the master, by deriving the xmin at the point the WAL record arrives. We would calculate it by looking at recovery procs only. That will likely give us a later value than we would get from the master, but that can't be helped. Hmm, that's an interesting idea. It presumes that we see an abort/commit WAL record at the right moment for every transaction that we have a recovery proc for. We just concluded in the other thread that we do always emit abortion records when the database is running normally; I think that's good enough for this purpose. A few other random ideas I had: - in btree delete redo, follow the index pointers, and look at the xids on the heap tuples. That requires some random I/O, but will give the exact value we need. Since it's quite expensive, I think we'd only want to do it after using some more conservative test but quicker test to determine that there might be a conflict. - Add latestRemovedXid to b-tree page header, and update it as tuples are killed. Need to tolerate the fact that tuple kills are not WAL-logged. Btree deletes were an important optimisation when it first went it, but now we have HOT it is much less important. If HOT is working well for your application, there won't be many btree deletes anyway, and the whole issue is moot. Another route might be to put an option to turn off btree delete on the master, default = on. We probably should consider turning it off entirely when it doesn't yield significant benefit. I'd rather put in a generic mechanism to prevent vacuuming of recent tuples that might still be needed in the standby. Like always subtracting a fixed amount of xids from OldestXmin/RecentGlobalXmin, or having a feedback loop from the standby to the master, allowing the master to say what it's oldest xmin is. But that's a fair amount of work; I'd rather leave that as a future enhancement, and just figure out something simple for this specific issue. We'll need to handle it gracefully even if we try to avoid it by retaining dead tuples longer. Lots of scanning to remove the odd row is probably pretty wasteful and likely adds contention at the very point we don't want it - index splits. Remember that if you can remove enough dead tuples from the index page, you've just made room on the page and don't need to split. Splitting is pretty expensive compared to scanning a few line pointers. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby dev build (v8)
On Mon, 2009-01-19 at 15:47 +0200, Heikki Linnakangas wrote: Simon Riggs wrote: I suggest we handle this on the recovery side, not on the master, by deriving the xmin at the point the WAL record arrives. We would calculate it by looking at recovery procs only. That will likely give us a later value than we would get from the master, but that can't be helped. Hmm, that's an interesting idea. It presumes that we see an abort/commit WAL record at the right moment for every transaction that we have a recovery proc for. We just concluded in the other thread that we do always emit abortion records when the database is running normally; I think that's good enough for this purpose. But not perfect. A few other random ideas I had: - in btree delete redo, follow the index pointers, and look at the xids on the heap tuples. That requires some random I/O, but will give the exact value we need. Since it's quite expensive, I think we'd only want to do it after using some more conservative test but quicker test to determine that there might be a conflict. Ouch. - Add latestRemovedXid to b-tree page header, and update it as tuples are killed. Need to tolerate the fact that tuple kills are not WAL-logged. Sounds easy-ish. If tuple kills aren't WAL logged then if we crash latestRemovedXid will remain as it was at time of last write. So if we do a delete scan it will only remove the index tuples with hint bits set at time of that write, so the value would always be correct, no? I'm somehow uncomfortable with this idea though. Care to persuade me further? Btree deletes were an important optimisation when it first went it, but now we have HOT it is much less important. If HOT is working well for your application, there won't be many btree deletes anyway, and the whole issue is moot. That was my point. Another route might be to put an option to turn off btree delete on the master, default = on. We probably should consider turning it off entirely when it doesn't yield significant benefit. I'd rather put in a generic mechanism to prevent vacuuming of recent tuples that might still be needed in the standby. Like always subtracting a fixed amount of xids from OldestXmin/RecentGlobalXmin, or having a feedback loop from the standby to the master, allowing the master to say what it's oldest xmin is. But that's a fair amount of work; I'd rather leave that as a future enhancement, and just figure out something simple for this specific issue. We'll need to handle it gracefully even if we try to avoid it by retaining dead tuples longer. Yeh, looked at both of those also. Definitely after sync rep goes in though. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby dev build (v8)
On Mon, 2009-01-19 at 12:54 +, Simon Riggs wrote: Some refactoring in this area is also required because we need to handle two other types of conflict to correctly support drop database and drop user, which is now underway. I've hung the drop database conflict code in dbase_redo(). For drop role, there isn't an rmgr at all, but I can add code in a few places. * add XLOG_DBASE_DROP_USER - i.e. add drop user to the Database rmgr * DropRole() takes an AccessExclusiveLock, so we do write a WAL record for it. I could add a special case to the Relation rmgr. * Add a new rmgr (unused slot 7) and have it handle DropRole. I prefer the last one, but if you think otherwise, please shout. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #4186: set lc_messages does not work
Hiroshi Inoue wrote:
Hiroshi Inoue wrote:
Magnus Hagander wrote:
Do you want to send an updated patch for it, or do you want me to look
at it?
I would send a new patch to which I added a simple ISO style check for
locale names.
Attached is a new patch.
I added a simple ISO style locale name check.
Avoided codings like *NULL == somthing*.
It also includes the changes to mbutils.c and elog.c which fix
recently introduced bug by the domain name change from postgres
to postgres-8.4.
Attached is a further updated version of this patch. Changes include:
* Actually avoid NULL==something style coding everywhere (I think)
* Avoid coding like if (ret = putenvFunc(envval), 0 != ret)
* Per discussion, remove pg_locale.c specific coding, put it in
src/port, and do a redefine so we *always* use these new functions
* Some further minor cleanups
* Removed the change to mbutils.c and elog.c - those are a separate
issue, will deal with those as a separate patch.
There still needs to be some error checking added in IsoLocaleName(),
but this is a start.
Can someone please test this? :-) I can't get NLS to work at all in my
Windows install (this is nothing new, it's always been tricky) right
now. I'll work on trying to fix that, but help with testing would be
very useful meanwhile.
(It passes build on MSVC, it's just runtime i can't check)
//Magnus
*** a/configure
--- b/configure
***
*** 17920,17925 case $LIBOBJS in
--- 17920,17931
esac
case $LIBOBJS in
+ * win32env.$ac_objext * ) ;;
+ *) LIBOBJS=$LIBOBJS win32env.$ac_objext
+ ;;
+ esac
+
+ case $LIBOBJS in
* win32error.$ac_objext * ) ;;
*) LIBOBJS=$LIBOBJS win32error.$ac_objext
;;
*** a/configure.in
--- b/configure.in
***
*** 1274,1279 AC_REPLACE_FUNCS(gettimeofday)
--- 1274,1280
AC_LIBOBJ(kill)
AC_LIBOBJ(open)
AC_LIBOBJ(rand)
+ AC_LIBOBJ(win32env)
AC_LIBOBJ(win32error)
AC_DEFINE([HAVE_SYMLINK], 1,
[Define to 1 if you have the `symlink' function.])
*** a/src/backend/utils/adt/pg_locale.c
--- b/src/backend/utils/adt/pg_locale.c
***
*** 55,60
--- 55,63
#include utils/memutils.h
#include utils/pg_locale.h
+ #ifdef WIN32
+ #include shlwapi.h
+ #endif
#define MAX_L10N_DATA 80
***
*** 89,94 static char lc_monetary_envbuf[LC_ENV_BUFSIZE];
--- 92,101
static char lc_numeric_envbuf[LC_ENV_BUFSIZE];
static char lc_time_envbuf[LC_ENV_BUFSIZE];
+ #ifdef WIN32
+ static char *IsoLocaleName(const char *); /* MSVC specific */
+ #endif
+
/*
* pg_perm_setlocale
***
*** 148,155 pg_perm_setlocale(int category, const char *locale)
case LC_MESSAGES:
envvar = LC_MESSAGES;
envbuf = lc_messages_envbuf;
break;
! #endif
case LC_MONETARY:
envvar = LC_MONETARY;
envbuf = lc_monetary_envbuf;
--- 155,167
case LC_MESSAGES:
envvar = LC_MESSAGES;
envbuf = lc_messages_envbuf;
+ #ifdef WIN32
+ result = IsoLocaleName(locale);
+ if (result == NULL)
+ result = locale;
+ #endif /* WIN32 */
break;
! #endif /* LC_MESSAGES */
case LC_MONETARY:
envvar = LC_MONETARY;
envbuf = lc_monetary_envbuf;
***
*** 166,190 pg_perm_setlocale(int category, const char *locale)
elog(FATAL, unrecognized LC category: %d, category);
envvar = NULL; /* keep compiler quiet */
envbuf = NULL;
! break;
}
snprintf(envbuf, LC_ENV_BUFSIZE - 1, %s=%s, envvar, result);
- #ifndef WIN32
if (putenv(envbuf))
return NULL;
- #else
-
- /*
- * On Windows, we need to modify both the process environment and the
- * cached version in msvcrt
- */
- if (!SetEnvironmentVariable(envvar, result))
- return NULL;
- if (_putenv(envbuf))
- return NULL;
- #endif
return result;
}
--- 178,190
elog(FATAL, unrecognized LC category: %d, category);
envvar = NULL; /* keep compiler quiet */
envbuf = NULL;
! return NULL;
}
snprintf(envbuf, LC_ENV_BUFSIZE - 1, %s=%s, envvar, result);
if (putenv(envbuf))
return NULL;
return result;
}
***
*** 599,601 cache_locale_time(void)
--- 599,650
CurrentLCTimeValid = true;
}
+
+
+ #ifdef WIN32
+ /*
+ * Convert Windows locale name to the ISO formatted one
+ * if possible.
+ *
+ * This function returns NULL if conversion is impossible,
+ * otherwise returns the pointer to a static area which
+ * contains the iso formatted locale name.
+ */
+ static
+ char *IsoLocaleName(const char *winlocname)
+ {
+ #if (_MSC_VER = 1400) /* VC8.0 or later */
+
+ static char iso_lc_messages[32];
+ _locale_t loct = NULL;
+
+ if (pg_strcasecmp(c, winlocname) == 0 ||
+ pg_strcasecmp(posix, winlocname) == 0)
+ {
+ strncpy(iso_lc_messages, C, sizeof(iso_lc_messages));
+ return iso_lc_messages;
+ }
+
+ loct = _create_locale(LC_CTYPE, winlocname);
+ if (loct != NULL)
+ {
+ char isolang[32],
Re: [HACKERS] Review: B-Tree emulation for GIN
Jeff Davis escribió: I like the fact that this patch does not modify the numeric ADT. It still relies on the fact that the numeric type will never make use of the minimal varlena struct, however. I bring this up in case someone sees it as a problem. Greg Stark was working on a patch to make certain values use the short representation. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby dev build (v8)
Simon Riggs wrote: I prefer the last one, but if you think otherwise, please shout. We're now emitting WAL records for relcache invalidations, IIRC. I wonder if those are useful for this? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Textdomains
I've extracted this patch from Hiroshi Inoues patch about bug #4186. Per his comment, It also includes the changes to mbutils.c and elog.c which fix recently introduced bug by the domain name change from postgres to postgres-8.4. Can somebody who actually knows how that works comment on it, please :-) //Magnus diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c index 89163d6..a33c94e 100644 --- a/src/backend/utils/error/elog.c +++ b/src/backend/utils/error/elog.c @@ -308,7 +308,7 @@ errstart(int elevel, const char *filename, int lineno, edata-lineno = lineno; edata-funcname = funcname; /* the default text domain is the backend's */ - edata-domain = domain ? domain : postgres; + edata-domain = domain ? domain : PG_TEXTDOMAIN(postgres); /* Select default errcode based on elevel */ if (elevel = ERROR) edata-sqlerrcode = ERRCODE_INTERNAL_ERROR; diff --git a/src/backend/utils/mb/mbutils.c b/src/backend/utils/mb/mbutils.c index 3467c31..7725df4 100644 --- a/src/backend/utils/mb/mbutils.c +++ b/src/backend/utils/mb/mbutils.c @@ -873,7 +873,7 @@ SetDatabaseEncoding(int encoding) */ #ifdef ENABLE_NLS if (encoding == PG_UTF8) - if (bind_textdomain_codeset(postgres, UTF-8) == NULL) + if (bind_textdomain_codeset(textdomain(NULL), UTF-8) == NULL) elog(LOG, bind_textdomain_codeset failed); #endif } -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
tsearch with Turkish locale ( was Re: [HACKERS] foreign_data test fails with non-C locale)
Devrim GÜNDÜZ wrote:
Yep, I ran them already, and as you wrote, I'm getting 3 errors (tsearch
tests + foreign_data test).
And then use your language skills to determine what the correct
behavior is. ;-)
SKIES would be skıes (dotless i).
Here is the conversion table:
I (capital) - ı
İ (capital - i
I think the test show that there is a bug in the tsearch support for
Turkish. Here is the test diff:
--- expected/tsearch.out2008-10-18 12:56:29.0 +0300
+++ results/tsearch.out 2009-01-19 16:26:51.0 +0200
@@ -962,38 +962,38 @@
SELECT to_tsvector('SKIES My booKs');
to_tsvector
- 'books':3 'my':2 'skies':1
+ 'books':3 'my':2 'skIes':1
(1 row)
[and more of the same]
This is not correct under either Turkish or non-Turkish language rules.
Note that
postgres=# select lower('SKIES');
lower
---
skıes
(1 row)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use.
Hiroshi Inoue wrote: Hiroshi Inoue wrote: Bruce Momjian wrote: Hiroshi, is this patch still needed? Yes though it should be slightly changed now. In what way should it be changed? //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Textdomains
Magnus Hagander wrote: I've extracted this patch from Hiroshi Inoues patch about bug #4186. Per his comment, It also includes the changes to mbutils.c and elog.c which fix recently introduced bug by the domain name change from postgres to postgres-8.4. Can somebody who actually knows how that works comment on it, please :-) It looks correct. Note, however, that we now support translation of loaded modules, so you would really need to go around and call bind_textdomain_codeset() for all catalogs that pop up dynamically. So that part might need some more work. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Textdomains
Peter Eisentraut wrote: Magnus Hagander wrote: I've extracted this patch from Hiroshi Inoues patch about bug #4186. Per his comment, It also includes the changes to mbutils.c and elog.c which fix recently introduced bug by the domain name change from postgres to postgres-8.4. Can somebody who actually knows how that works comment on it, please :-) It looks correct. Ok, will apply. Note, however, that we now support translation of loaded modules, so you would really need to go around and call bind_textdomain_codeset() for all catalogs that pop up dynamically. So that part might need some more work. Well, this is a bugfix for existing stuff... Adding new stuff I'll happily leave to someone who understands it better.. :-P //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot Standby dev build (v8)
On Mon, 2009-01-19 at 16:50 +0200, Heikki Linnakangas wrote: Simon Riggs wrote: I prefer the last one, but if you think otherwise, please shout. We're now emitting WAL records for relcache invalidations, IIRC. I wonder if those are useful for this? Tom already objected to putting strange inval messages into WAL. Hmm, DROP USER is transactional, so we can only do this at commit. So forget the other ideas I had. We already know about the auth file update at commit. So we should say, at commit, re-read the list of roleids in use and if any don't match a row in pg_user then remove them. If we do that after the flat file update and the actual commit that removes the user then we will be guaranteed no race condition exists to allow new users to logon as we try to disconnect them. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] number of connections
Hi! First of all, excuse my english... I have a doubt. I am designing a program for manage CV's. This program connect with a PostgresDB. This program will be used for 5,000 persons becaus it will be used in a University. Then, ¿how many actives connection could be postgres? ¿does it support a very big cuantity of information? Possibly, in the future, the program will grow up with more information and more users. ¿can i use in this case postgres?¿has it a good scalability? Thank you. Ruben FS
Re: [HACKERS] libpq WSACleanup is not needed
Andrew Chernow wrote: James Mansion wrote: Is there a need for a new API to control this - can't you just interpret another parameter keyword in PQconnectdb (or the pgoptions string in PQsetdbLogin I guess)? That's an interesting idea. I don't know if its the correct place to control this, but it does allow turning off wsastartup and indicating which winsock version to load. From a design perspective it seems like the wrong place to put it if you think of it as a general initialization. From the narrow perspective of wsastartup, it could work to add an option to inhibit it. But will it scale to future needs? //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review: B-Tree emulation for GIN
still relies on the fact that the numeric type will never make use of the minimal varlena struct, however. I bring this up in case someone sees it as a problem. Greg Stark was working on a patch to make certain values use the short representation. Fake value contains only VARHDRSZ bytes. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] libpq WSACleanup is not needed
Magnus Hagander wrote: Andrew Chernow wrote: James Mansion wrote: Is there a need for a new API to control this - can't you just interpret another parameter keyword in PQconnectdb (or the pgoptions string in PQsetdbLogin I guess)? That's an interesting idea. I don't know if its the correct place to control this, but it does allow turning off wsastartup and indicating which winsock version to load. From a design perspective it seems like the wrong place to put it if you think of it as a general initialization. From the narrow perspective of wsastartup, it could work to add an option to inhibit it. But will it scale to future needs? //Magnus yeah, it might be a stretch. It also ignores the other needs for a library init(). -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review: B-Tree emulation for GIN
Jeff Davis pg...@j-davis.com writes: I like the fact that this patch does not modify the numeric ADT. It still relies on the fact that the numeric type will never make use of the minimal varlena struct, however. I bring this up in case someone sees it as a problem. I'm pretty certain I recall Greg Stark recommending that we adopt something like that as the standard numeric representation of zero. It didn't get done yet, but it might happen someday. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Fixes for compiler warnings
Magnus Hagander escribió: For a change like http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.480r2=1.481 Will it work to stick _(hintmsg) around it there? Assuming that there is a gettext_noop() call in the literal that's assigned to hintmsg, yes, it should work. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] GIN improvements
Changes: Results of pernding list's scan now are placed directly in resulting tidbitmap. This saves cycles for filtering results and reduce memory usage. Also, it allows to not check losiness of tbm. Is this a 100% bulletproof solution, or is it still possible for a query to fail due to the pending list? It relies on the stats collector, so perhaps in rare cases it could still fail? Yes :( Can you explain why the tbm must not be lossy? The problem with lossy tbm has two aspects: - amgettuple interface hasn't possibility to work with page-wide result instead of exact ItemPointer. amgettuple can not return just a block number as amgetbitmap can. - Because of concurrent vacuum process: while we scan pending list, it's content could be transferred into regular structure of index and then we will find the same tuple twice. Again, amgettuple hasn't protection from that, only amgetbitmap has it. So, we need to filter results from regular GIN by results from pending list. ANd for filtering we can't use lossy tbm. v0.21 prevents from that fail on call of gingetbitmap, because now all results are collected in single resulting tidbitmap. Also, can you clarify why a large update can cause a problem? In the If query looks like UPDATE tbl SET col=... WHERE col ... and planner choose GIN indexscan over col then there is a probability of increasing of pending list over non-lossy limit. previous discussion, you suggested that it force normal index inserts after a threshold based on work_mem: http://archives.postgresql.org/pgsql-hackers/2008-12/msg00065.php I see only two guaranteed solution of the problem: - after limit is reached, force normal index inserts. One of the motivation of patch was frequent question from users: why update of whole table with GIN index is so slow? So this way will not resolve this question. - after limit is reached, force cleanup of pending list by calling gininsertcleanup. Not very good, because users sometimes will see a huge execution time of simple insert. Although users who runs a huge update should be satisfied. I have difficulties in a choice of way. Seems to me, the better will be second way: if user gets very long time of insertion then (auto)vacuum of his installation should tweaked. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ fast_insert_gin-0.21.gz Description: Unix tar archive -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] number of connections
On Tue, Jan 20, 2009 at 2:44 AM, Rubén F. rfs1...@gmail.com wrote: I have a doubt. I am designing a program for manage CV's. This program connect with a PostgresDB. This program will be used for 5,000 persons becaus it will be used in a University. Then, ¿how many actives connection could be postgres? ¿does it support a very big cuantity of information? Hi Ruben, Good questions, but you might want to ask them on the pgsql-gene...@postgresql.org mailing list or the IRC channel. The hackers list is reserved for discussion of postgres development. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review: B-Tree emulation for GIN
On Mon, 2009-01-19 at 11:35 -0500, Tom Lane wrote: Jeff Davis pg...@j-davis.com writes: I like the fact that this patch does not modify the numeric ADT. It still relies on the fact that the numeric type will never make use of the minimal varlena struct, however. I bring this up in case someone sees it as a problem. I'm pretty certain I recall Greg Stark recommending that we adopt something like that as the standard numeric representation of zero. It didn't get done yet, but it might happen someday. Then we should use the previous version of the patch here: http://archives.postgresql.org/message-id/1231709713.25019.129.ca...@jdavis Was there any talk of supporting a +/- infinity in numeric? If we did that, it would allow numeric to be supported for btree-gin. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] GIN improvements
Teodor Sigaev wrote: New version. Changes: - synced with current CVS I notice you added a fillfactor reloption in ginoptions, but does it really make sense? I recall removing it because the original code contained a comment that says this is here because default_reloptions wants it, but it has no effect. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review: B-Tree emulation for GIN
I'm pretty certain I recall Greg Stark recommending that we adopt something like that as the standard numeric representation of zero. It didn't get done yet, but it might happen someday. Changes: - use NULL as left-most value. It's safe because NULL numeric value cannot be an argument for any function except gin_numeric_cmp and it cannot be returned in regular SQL query. - fix uninstall script for support numeric type. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ btree_gin-0.8.gz Description: Unix tar archive -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] GIN improvements
I notice you added a fillfactor reloption in ginoptions, but does it really make sense? I recall removing it because the original code contained a comment that says this is here because default_reloptions wants it, but it has no effect. I didn't change a recognition of fillfactor value, although GIN doesn't use it for now. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Fixes for compiler warnings
Alvaro Herrera alvhe...@commandprompt.com writes: Magnus Hagander escribió: For a change like http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.480r2=1.481 Will it work to stick _(hintmsg) around it there? Assuming that there is a gettext_noop() call in the literal that's assigned to hintmsg, yes, it should work. ... and if there isn't, it's not this code's fault ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] GIN improvements
Teodor Sigaev wrote: I notice you added a fillfactor reloption in ginoptions, but does it really make sense? I recall removing it because the original code contained a comment that says this is here because default_reloptions wants it, but it has no effect. I didn't change a recognition of fillfactor value, although GIN doesn't use it for now. I suggest you take StdRdOptions out of the GinOptions struct, and leave fillfactor out of ginoptions. I don't think there's much point in supporting options that don't actually do anything. If the user tries to set fillfactor for a gin index, he will get an error. Which is a good thing IMHO. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: tsearch with Turkish locale ( was Re: [HACKERS] foreign_data test fails with non-C locale)
I think the test show that there is a bug in the tsearch support for Turkish. Here is the test diff: How to reproduce that? % psql -l List of databases Name| Owner | Encoding | Collation |Ctype| Access privileges ++--+-+-+--- postgres | pgsql | UTF8 | tr_TR.UTF-8 | tr_TR.UTF-8 | regression | teodor | UTF8 | tr_TR.UTF-8 | tr_TR.UTF-8 | % ./pg_regress --inputdir=. --dlpath=. --multibyte=UTF8 --load-language=plpgsql --top-builddir=../../.. --schedule=./parallel_schedule ... === All 120 tests passed. === -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] GIN improvements
Alvaro Herrera alvhe...@commandprompt.com writes: Teodor Sigaev wrote: I didn't change a recognition of fillfactor value, although GIN doesn't use it for now. I suggest you take StdRdOptions out of the GinOptions struct, and leave fillfactor out of ginoptions. I don't think there's much point in supporting options that don't actually do anything. If the user tries to set fillfactor for a gin index, he will get an error. Which is a good thing IMHO. +1 ... appearing to accept an option that doesn't really do anything is likely to confuse users. We didn't have much choice in the previous incarnation of reloptions, but I think now we should throw errors when we can. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review: B-Tree emulation for GIN
On Mon, 2009-01-19 at 20:15 +0300, Teodor Sigaev wrote: Changes: - use NULL as left-most value. It's safe because NULL numeric value cannot be an argument for any function except gin_numeric_cmp and it cannot be returned in regular SQL query. gin_numeric_cmp() can be called from regular SQL. I missed this before, but that function will segfault if you call gin_numeric_cmp(NULL, 1) (in v0.7 at least). I know you mean a C NULL, not a SQL NULL, but it reminded me to test SQL NULL. And how does GIN handle SQL NULL values in the column? Does it index them at all, or just ignore them? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] GIN improvements
I suggest you take StdRdOptions out of the GinOptions struct, and leave fillfactor out of ginoptions. I don't think there's much point in supporting options that don't actually do anything. If the user tries to set fillfactor for a gin index, he will get an error. Which is a good thing IMHO. Oh, I see. Fixed. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ fast_insert_gin-0.22.gz Description: Unix tar archive -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: tsearch with Turkish locale ( was Re: [HACKERS] foreign_data test fails with non-C locale)
On Mon, 2009-01-19 at 20:45 +0300, Teodor Sigaev wrote:
How to reproduce that?
-bash-3.2$ psql -l
List of databases
Name| Owner | Encoding | Collation |Ctype| Access
Privileges
+--+--+-+-+-
postgres | postgres | UTF8 | tr_TR.UTF-8 | tr_TR.UTF-8 |
regression | postgres | UTF8 | tr_TR.UTF-8 | tr_TR.UTF-8 |
template0 | postgres | UTF8 | tr_TR.UTF-8 | tr_TR.UTF-8 |
{=c/postgres,postgres=CTc/postgres}
template1 | postgres | UTF8 | tr_TR.UTF-8 | tr_TR.UTF-8 |
{=c/postgres,postgres=CTc/postgres}
(4 rows)
-bash-3.2$ ./pg_regress --inputdir=. --dlpath=. --multibyte=UTF8
--load-language=plpgsql --top-builddir=../../.. --schedule=./parallel_schedule
(using postmaster on Unix socket, default port)
snip
timestamp... FAILED
timestamptz ... FAILED
snip
tsearch ... FAILED
tsdicts ... FAILED
foreign_data ... FAILED
5 of 120 tests failed.
This is on a Fedora-9 x86 box, and:
-bash-3.2$ rpm -qv glibc
glibc-2.8-8.i686
Regards,
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org
signature.asc
Description: This is a digitally signed message part
Re: [HACKERS] Review: B-Tree emulation for GIN
gin_numeric_cmp() can be called from regular SQL. I missed this before, but that function will segfault if you call gin_numeric_cmp(NULL, 1) (in v0.7 at least). Fixed, gin_numeric_cmp is marked as strict. And how does GIN handle SQL NULL values in the column? Does it index them at all, or just ignore them? SQL NULL: GIN doesn't support it (amindexnulls/amsearchnulls == false) C NULL: NULL-numeric could be returned only by gin_extract_query_numeric which cannot be called by user directly because of internal type of argument. GIN doesn't do anything with values returned by gin_extract_query_numeric except providing they as an argument for comparing functions. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ btree_gin-0.9.gz Description: Unix tar archive -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: tsearch with Turkish locale ( was Re: [HACKERS] foreign_data test fails with non-C locale)
5 of 120 tests failed. This is on a Fedora-9 x86 box, and: -bash-3.2$ rpm -qv glibc glibc-2.8-8.i686 Interesting. On my notebook all is ok. % uname -a FreeBSD ... 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2 Is any possibility of broken locale? -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review: B-Tree emulation for GIN
On Mon, 2009-01-19 at 21:41 +0300, Teodor Sigaev wrote: And how does GIN handle SQL NULL values in the column? Does it index them at all, or just ignore them? SQL NULL: GIN doesn't support it (amindexnulls/amsearchnulls == false) C NULL: NULL-numeric could be returned only by gin_extract_query_numeric which cannot be called by user directly because of internal type of argument. GIN doesn't do anything with values returned by gin_extract_query_numeric except providing they as an argument for comparing functions. Ok, I understand now. I will look at this later. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] libpq WSACleanup is not needed
James Mansion wrote: Magnus Hagander wrote: The use-case of rapidly creating and dropping connections isn't particularly common, I think. And there is a perfectly functioning workaround - something that we should perhaps document in the FAQ or somewhere in the documentation? Would it be accetable to do initialise if the number of connections is changing from 0, and tidy if the cumber goes back to 0? Applications that retain a connection would not suffer the cost on subsequent connect/disconnect. Yes, we do that now to clear the SSL callbacks in libpq (see variable 'ssl_open_connections'): CRYPTO_set_locking_callback(NULL); CRYPTO_set_id_callback(NULL); If we don't remove them when going to zero connections then unloading libpq can cause PHP to crash because it thinks the callback functions are still loaded. We could have gone with a more elegant init/uninit solution but there is a history of slow upstream adoption of libpq API changes. In this case I am thinking WSACleanup() should probably follow the same pattern. Having load/unload is superior, but if adoption of that API is 10%, you will probably get the most advantage for the most users in making it automatic. The one big difference with SSL is that the SSL callback unload calls where cheap, while WSACleanup() is expensive. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] libpq WSACleanup is not needed
Bruce Momjian wrote: We could have gone with a more elegant init/uninit solution but there is a history of slow upstream adoption of libpq API changes. If that's the case, adding a connectdb option seems like a good alternative. Orignally suggested here: http://archives.postgresql.org/pgsql-hackers/2009-01/msg01358.php -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] libpq WSACleanup is not needed
Andrew Chernow wrote: Bruce Momjian wrote: We could have gone with a more elegant init/uninit solution but there is a history of slow upstream adoption of libpq API changes. If that's the case, adding a connectdb option seems like a good alternative. Orignally suggested here: http://archives.postgresql.org/pgsql-hackers/2009-01/msg01358.php Right, well the big question is how many people are going to use the connection option vs. doing it for everyone automatically. One possible approach might be to do it automatically, and allow a connection option to disable the WSACleanup() call. Actually, right now, if you have two libpq connections, and close one, does WSACleanup() get called, and does it affect the existing connection? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] foreign_data test fails with non-C locale
Andrew Dunstan píše v pá 09. 01. 2009 v 12:16 -0500: Guillaume Smet wrote: On Fri, Jan 9, 2009 at 5:24 PM, Tom Lane t...@sss.pgh.pa.us wrote: However, the de facto policy is that we try to keep them passing in locales that are used by any of the regular developers. I think it would be useful to have buildfarm members testing in a few common locales. If you define common locales, I can set up as many new animals as needed to cover the locales needed for any branch we'd like to test. Perhaps we should add a parameter to the buildfarm config file so that the buildfarm script can check the locale is accepted and set it directly. Considering that we won't have the locale information in the animal description, it's a good way to have it in the report. Sure, we can easily have buildfarm's initdb step set any locale (and encoding, for that matter) we like. That's a simple change. Will be possible to set more locales and run tests without recompilation on all of them? For example I have installed all Solaris'es locales on my animal, but currently it means that I need perform whole cycle for each locale. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] foreign_data test fails with non-C locale
Peter Eisentraut píše v ne 11. 01. 2009 v 12:54 +0200: The remaining 80 failures are more-or-less linguistic issues that belong to the following 26 language/country combinations: cs_CZ sorts ch separately; sorts st = s s st Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WIP: Automatic view update rules
--On Samstag, Januar 17, 2009 02:01:15 +0200 Peter Eisentraut pete...@gmx.net wrote: Here is my updated patch based on yours. Outstanding issues, as far as I can see, are: Critical: * Updatability check must reject views where the select list references the same column more than once. checkTree() will recheck this against reused varattno's within the query tree and will reject such view definitions as non-updatable now. * Various scenarios of REPLACE VIEW misbehave. I have marked these as FIXME in the regression test. I think all this would behave better if REPLACE VIEW dropped all automatic rules and reassembled them from scratch for the new view. The infrastructure for this is already there, so it should be a small change. DefineViewRules() will drop all implicit rules when REPLACE is used now. Important: * Array support should be clarified. checkTree() appears to reject most variants of array references, but other parts of the code try to handle it. Should be cleaned up. I'm currently working on this. * It is not clear how automatic rules and manual DO ALSO rules should interact. A manual DO ALSO rule will currently clear out an automatic INSTEAD rule, which I find to be illogical. What i've done so far is to replace implicit DO INSTEAD rules only, when the new explicit one is DO INSTEAD, too. An additional DO ALSO rule will be added to the view without dropping any automatic rules now. Optional: * The use of must_replace is create_update_rule() seems a bit useless. You might as well just always pass replace = true. Fixed * You may want to consider writing the rule qualifications WHERE ((CASE WHEN (old.a IS NOT NULL) THEN (old.a = vutestv20.x) ELSE (vutestv20.x IS NULL) END)) more like WHERE ((old.a = vutestv20.x) OR (old IS NULL AND vutestv20.x IS NULL)) for better optimizability. Done. Please note that i haven't fixed the regression test yet. Thanks very much for reviewing! -- Thanks Bernd view_update_20090119.patch.bz2 Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] is 8.4 array_agg() supposed to work with array values?
Hi,
The docs at
http://developer.postgresql.org/pgdocs/postgres/functions-aggregate.html
don't prohibit using array values with array_arg(), so I assumed that it would
work.
However, with CVS HEAD from Friday afternoon, I get
test= select version() ;
version
--
PostgreSQL 8.4devel on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC)
4.1.2 20070502 (Red Hat 4.1.2-12), 64-bit
(1 row)
test= select v.a, pg_typeof(v.a) from (values (array[1,2]), (array[3,4])) as
v(a) ;
a | pg_typeof
---+---
{1,2} | integer[]
{3,4} | integer[]
(2 rows)
test= select array_agg(v.a) from (values (array[1,2]), (array[3,4])) as v(a) ;
ERROR: could not find array type for data type integer[]
test=
If this is expected behavior, the docs should mention the restriction.
-- todd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Meridiem markers (was: [BUGS] Incorrect invalid AM/PM string error from to_timestamp)
On Sat, Sep 27, 2008 at 4:25 AM, Brendan Jurd dire...@gmail.com wrote:
One way to tidy this up would be to re-implement the meridiem markers
using the seq_search functions, i.e., make it work like the day and
month names. This would make it easy to accept any flavour of marker,
and the error messages thrown for bogus input would then be the same
as those for bogus day and month names.
From the better-late-than-never department, comes a patch to improve
the handling of AM/PM and AD/BC markers in to_timestamp(), and up the
ante on error reporting for various kinds of invalid input.
The only difference as far as parsing goes is that we no longer worry
about the case of AM/PM and AD/BC. As long as you use the right
variation for with/without periods, it will parse.
Internally, the code now uses seq_search to parse the markers, so they
work in much the same way as month and day names do.
I improved the error messages for when a seq_search fails, and when
the code fails to parse an integer. Some examples of the new error
messages:
postgres=# select to_timestamp('Tue 20 Foo 2009 11:39 PM', 'Dy DD Mon
HH:MI PM');
ERROR: invalid value Foo for Mon
DETAIL: The given value did not match any of the allowed values for this field.
postgres=# select to_timestamp('Tue 20 Jan 2009 11:39 pn', 'Dy DD Mon
HH:MI PM');
ERROR: invalid value PN for PM
DETAIL: The given value did not match any of the allowed values for this field.
postgres=# select to_timestamp('Tue 20 Jan 2009 23:39', 'Dy DD Mon HH:MI');
ERROR: hour 23 is invalid for the 12-hour clock
HINT: Use the 24-hour clock, or give an hour between 1 and 12.
postgres=# select to_timestamp('Tue 20 Jan 2009 xx:39 pm', 'Dy DD Mon
HH:MI PM');
ERROR: invalid value xx for HH
DETAIL: Value must be an integer.
This resolves TODO item Improve to_timestamp() handling of AM/PM, and
error messages. I've added the patch to the 2009 commitfest.
Cheers,
BJ
doc/src/sgml/func.sgml | 24 +--
src/backend/utils/adt/formatting.c | 235 -
src/test/regress/expected/horology.out | 10 -
src/test/regress/sql/horology.sql |4
4 files changed, 137 insertions(+), 136 deletions(-)
ampm-seqsearch.diff.bz2
Description: BZip2 compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Statement-level triggers and inheritance
Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: On Thursday 15 January 2009 02:08:42 Bruce Momjian wrote: Added to TODO: Have statement-level triggers fire for all tables in an inheritance hierarchy I don't think that was really the conclusion from the thread. As far as I can interpret the opinions, statement level triggers should fire on the parent table only, rather than on some child, as it currently does. I think the consensus was that each table should have its own statement triggers (if any) fire. Which is one possible reading of Bruce's TODO item, but it's surely not clearly worded. Sorry I had that wording wrong; TODO updated to: When statement-level triggers are defined on a parent table, have them fire only on the parent table, and fire child table triggers only where appropriate -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] FWD: Re: Updated backslash consistency patch
Gregory Stark wrote:
The behaviour of \dt in the face of tables which shadow system tables is
actually even stranger:
postgres=# create table pg_proc (t text);
CREATE TABLE
postgres=# commit;
COMMIT
postgres=# \dt pg_proc
No matching relations found.
And I don't see any reason aggregates, operators, etc, shouldn't be any more
susceptible the shadowing problem.
The inconsistency between \d and \dt is not defensible, and no one said
they liked it. Here is an example:
test= \d pg_language
-- Table pg_catalog.pg_language
Column | Type| Modifiers
---+---+---
lanname | name | not null
lanowner | oid | not null
lanispl | boolean | not null
lanpltrusted | boolean | not null
lanplcallfoid | oid | not null
lanvalidator | oid | not null
lanacl| aclitem[] |
Indexes:
pg_language_name_index UNIQUE, btree (lanname)
pg_language_oid_index UNIQUE, btree (oid)
test= \dt pg_language
-- No matching relations found.
As you can see, \d shows system tables, while \dt does not. The
attached patch makes \d and \dt consistent:
test= \d pg_language
Did not find any relation named pg_language.
test= \dt pg_language
No matching relations found.
test= \dS pg_language
Table pg_catalog.pg_language
Column | Type| Modifiers
---+---+---
lanname | name | not null
lanowner | oid | not null
lanispl | boolean | not null
lanpltrusted | boolean | not null
lanplcallfoid | oid | not null
lanvalidator | oid | not null
lanacl| aclitem[] |
Indexes:
pg_language_name_index UNIQUE, btree (lanname)
pg_language_oid_index UNIQUE, btree (oid)
test= \dtS pg_language
List of relations
Schema |Name | Type | Owner
+-+---+--
pg_catalog | pg_language | table | postgres
(1 row)
In pre-8.4, 'S' was recognised only by \dt.
The other part of the patch shows system and _user_ tables when \dtS is
used, to be consistent with the rest of the \d* commands.
I know we don't like the current behavior, but I think we need to make
them consistent first for easy testing and so when we change it, it will
remain consistent.
Applied. I will work on a consensus patch soon for the new behavior.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/bin/psql/command.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/command.c,v
retrieving revision 1.201
diff -c -c -r1.201 command.c
*** src/bin/psql/command.c 6 Jan 2009 21:10:30 - 1.201
--- src/bin/psql/command.c 20 Jan 2009 02:02:17 -
***
*** 334,347
OT_NORMAL, NULL, true);
show_verbose = strchr(cmd, '+') ? true : false;
! show_system = strchr(cmd, 'S') ? true: false;
switch (cmd[1])
{
case '\0':
case '+':
if (pattern)
! success = describeTableDetails(pattern, show_verbose);
else
/* standard listing of interesting things */
success = listTables(tvs, NULL, show_verbose, show_system);
--- 334,348
OT_NORMAL, NULL, true);
show_verbose = strchr(cmd, '+') ? true : false;
! show_system = strchr(cmd, 'S') ? true : false;
switch (cmd[1])
{
case '\0':
case '+':
+ case 'S':
if (pattern)
! success = describeTableDetails(pattern, show_verbose, show_system);
else
/* standard listing of interesting things */
success = listTables(tvs, NULL, show_verbose, show_system);
***
*** 390,396
case 'v':
case 'i':
case 's':
- case 'S':
success = listTables(cmd[1], pattern, show_verbose, show_system);
break;
case 'u':
--- 391,396
Index: src/bin/psql/describe.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/describe.c,v
retrieving revision 1.196
diff -c -c -r1.196 describe.c
*** src/bin/psql/describe.c 19 Jan 2009 18:44:32 - 1.196
--- src/bin/psql/describe.c 20 Jan 2009 02:02:17 -
***
*** 782,788
* verbose: if true, this is \d+
*/
bool
! describeTableDetails(const char *pattern, bool verbose)
{
PQExpBufferData buf;
PGresult *res;
--- 782,788
* verbose: if true, this is \d+
*/
bool
! describeTableDetails(const char *pattern, bool verbose,
Re: [HACKERS] Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use.
Magnus Hagander wrote: Hiroshi Inoue wrote: Hiroshi Inoue wrote: Bruce Momjian wrote: Hiroshi, is this patch still needed? Yes though it should be slightly changed now. In what way should it be changed? One is already committed by you. [COMMITTERS] pgsql: Use the new text domain names Another is to bind the codeset EUC-JP for PG_EUC_JIS_2004 server encoding. Though EUC_JP and EUC_JIS_2004 aren't completely compatible, it seems OK in most cases. regards, Hiroshi Inoue -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] FWD: Re: Updated backslash consistency patch
Bruce Momjian wrote: I know we don't like the current behavior, but I think we need to make them consistent first for easy testing and so when we change it, it will remain consistent. I will work on a consensus patch soon for the new behavior. Here is what I hope is a consensus patch. It adds 'A' to show all objects, including system ones. It turns out that this is how 'S' works now in CVS, but 'S' is unclear because it suggests just system objects; 'A' for show 'all' objects seems clearer. I did not add any special handling for patterns: test= \df repeat List of functions Schema | Name | Result data type | Argument data types +--+--+- (0 rows) test= \dfA repeat List of functions Schema | Name | Result data type | Argument data types ++--+- pg_catalog | repeat | text | text, integer (1 row) I am afraid that special pattern rules are going to be too confusing. You can see only system objects by referencing pg_catalog: test= \dtA pg_catalog.pg_t* List of relations Schema | Name | Type | Owner +--+---+-- pg_catalog | pg_tablespace| table | postgres pg_catalog | pg_trigger | table | postgres pg_catalog | pg_ts_config | table | postgres pg_catalog | pg_ts_config_map | table | postgres pg_catalog | pg_ts_dict | table | postgres pg_catalog | pg_ts_parser | table | postgres pg_catalog | pg_ts_template | table | postgres pg_catalog | pg_type | table | postgres (8 rows) Patch attached. One interesting idea would be to assume 'A' if the a schema is specified in the pattern, so; \df pg_catalog.* would work without 'A'. With this patch, \d and \dt show only user tables, and \df shows only user functions. I think usability-wise, these are good, and \dA, \dtA, and \dfA include system tables and functions. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/ref/psql-ref.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v retrieving revision 1.218 diff -c -c -r1.218 psql-ref.sgml *** doc/src/sgml/ref/psql-ref.sgml 20 Jan 2009 02:38:37 - 1.218 --- doc/src/sgml/ref/psql-ref.sgml 20 Jan 2009 03:54:20 - *** *** 833,840 more information is displayed: any comments associated with the columns of the table are shown, as is the presence of OIDs in the table. ! The letter literalS/literal adds the listing of system ! objects; without literalS/literal, only non-system objects are shown. /para --- 833,840 more information is displayed: any comments associated with the columns of the table are shown, as is the presence of OIDs in the table. ! The letter literalA/literal adds the listing of system ! objects; without literalA/literal, only non-system objects are shown. /para *** *** 859,866 return type and the data types they operate on. If replaceable class=parameterpattern/replaceable is specified, only aggregates whose names match the pattern are shown. ! The letter literalS/literal adds the listing of system ! objects; without literalS/literal, only non-system objects are shown. /para /listitem --- 859,866 return type and the data types they operate on. If replaceable class=parameterpattern/replaceable is specified, only aggregates whose names match the pattern are shown. ! The letter literalA/literal adds the listing of system ! objects; without literalA/literal, only non-system objects are shown. /para /listitem *** *** 890,897 If replaceable class=parameterpattern/replaceable is specified, only conversions whose names match the pattern are listed. ! The letter literalS/literal adds the listing of system ! objects; without literalS/literal, only non-system objects are shown. /para /listitem --- 890,897 If replaceable class=parameterpattern/replaceable is specified, only conversions whose names match the pattern are listed. ! The letter literalA/literal adds the listing of system ! objects; without
Re: [HACKERS] [BUGS] BUG #4186: set lc_messages does not work
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Hiroshi Inoue wrote:
Magnus Hagander wrote:
Do you want to send an updated patch for it, or do you want me to look
at it?
I would send a new patch to which I added a simple ISO style check for
locale names.
Attached is a new patch.
I added a simple ISO style locale name check.
Avoided codings like *NULL == somthing*.
It also includes the changes to mbutils.c and elog.c which fix
recently introduced bug by the domain name change from postgres
to postgres-8.4.
Attached is a further updated version of this patch. Changes include:
Thanks.
* Actually avoid NULL==something style coding everywhere (I think)
* Avoid coding like if (ret = putenvFunc(envval), 0 != ret)
* Per discussion, remove pg_locale.c specific coding, put it in
src/port, and do a redefine so we *always* use these new functions
* Some further minor cleanups
* Removed the change to mbutils.c and elog.c - those are a separate
issue, will deal with those as a separate patch.
There still needs to be some error checking added in IsoLocaleName(),
but this is a start.
Can someone please test this? :-)
OK I would check it tonight.
Please note the patch relies on the proper gettext module.
The header, lib and dlls are placed on Saito-san's site
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/libintl_check/
.
Also note the current source tries to find the message catalog
postgres-8.4.mo not postgres.mo.
The attached is an example patch to change the name of mo files
at installation time. I'm not good at perl and there may be
cleaner way.
regards,
Hiroshi Inoue
*** Install_orig.pm Wed Sep 17 13:31:08 2008
--- Install.pm Sat Jan 10 21:15:59 2009
***
*** 460,465
--- 460,478
print Installing NLS files...;
EnsureDirectories($target, share/locale);
+
+ my $majorver;
+ open(F, src/include/pg_config.h) || confess Could not open file
pg_config.h\n;
+ while (F)
+ {
+ if (/^#define\s+PG_MAJORVERSION\s+([^]+)/)
+ {
+ $majorver = $1;
+ }
+ }
+ print majorver=$majorver\n;
+ close(F);
+
my @flist;
File::Find::find({wanted =
sub { /^nls\.mk\z/s
***
*** 481,487
EnsureDirectories($target, share/locale/$lang,
share/locale/$lang/LC_MESSAGES);
system(
! \$nlspath\\bin\\msgfmt\ -o
\$target\\share\\locale\\$lang\\LC_MESSAGES\\$prgm.mo\ $_
)
croak(Could not run msgfmt on $dir\\$_);
print .;
--- 494,500
EnsureDirectories($target, share/locale/$lang,
share/locale/$lang/LC_MESSAGES);
system(
! \$nlspath\\bin\\msgfmt\ -o
\$target\\share\\locale\\$lang\\LC_MESSAGES\\$prgm-$majorver.mo\ $_
)
croak(Could not run msgfmt on $dir\\$_);
print .;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] FWD: Re: Updated backslash consistency patch
Here is what I hope is a consensus patch. It adds 'A' to show all objects, including system ones. It turns out that this is how 'S' works now in CVS, but 'S' is unclear because it suggests just system objects; 'A' for show 'all' objects seems clearer. I think it's probably fine for S to mean include system objects rather than show only system objects. Everyone should be relatively used to S by now; I think it's less confusing to keep the same letter even if the behavior has been adjusted somewhat. Though others may disagree? (Although this met with some earlier opposition, mostly from Tom IIRC, I still think it might be useful to have a setting to control which types of system objects are displayed by default: the setting could be interpreted as a list of characters X for which \dX would include system objects even without S. This would allow people who liked the old behavior to mostly recreate it.) ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] is 8.4 array_agg() supposed to work with array values?
On Monday 19 January 2009 23:22:21 Todd A. Cook wrote: The docs at http://developer.postgresql.org/pgdocs/postgres/functions-aggregate.html don't prohibit using array values with array_arg(), so I assumed that it would work. test= select array_agg(v.a) from (values (array[1,2]), (array[3,4])) as v(a) ; ERROR: could not find array type for data type integer[] Yeah ... This is one of the weirdnesses of the PostgreSQL array implementation. integer[] and integer[][] etc. are actually the same type, just using a different number of dimensions internally. This would work much better if integer[][] where array of integer[], in the same way as integer[] is array of integer, in the way C deals with arrays. This is also a main reason why composite types and arrays don't mix orthogonally; there is no way to represent that in the system catalogs. To get back to your question, as far as array_agg() itself is concerned, it would probably work, but the rest of the sytem doesn't deal with it very well. You will probably be able to find a number of other places that break when trying to derive the array type from something that is already an array. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review: B-Tree emulation for GIN
On Mon, 2009-01-19 at 21:41 +0300, Teodor Sigaev wrote: gin_numeric_cmp() can be called from regular SQL. I missed this before, but that function will segfault if you call gin_numeric_cmp(NULL, 1) (in v0.7 at least). Fixed, gin_numeric_cmp is marked as strict. And how does GIN handle SQL NULL values in the column? Does it index them at all, or just ignore them? SQL NULL: GIN doesn't support it (amindexnulls/amsearchnulls == false) C NULL: NULL-numeric could be returned only by gin_extract_query_numeric which cannot be called by user directly because of internal type of argument. GIN doesn't do anything with values returned by gin_extract_query_numeric except providing they as an argument for comparing functions. Ok, looks good. I updated the wiki to show this as the latest version of the patch. Thanks, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] foreign_data test fails with non-C locale
On Monday 19 January 2009 22:39:30 Zdenek Kotala wrote: Peter Eisentraut píše v ne 11. 01. 2009 v 12:54 +0200: The remaining 80 failures are more-or-less linguistic issues that belong to the following 26 language/country combinations: cs_CZ sorts ch separately; sorts st = s s st I had initially misinterpreted the failures. The real difference is that Czech sorts numbers after letters, most other locales do it the other way around. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: tsearch with Turkish locale ( was Re: [HACKERS] foreign_data test fails with non-C locale)
Teodor Sigaev wrote:
5 of 120 tests failed.
This is on a Fedora-9 x86 box, and:
-bash-3.2$ rpm -qv glibc
glibc-2.8-8.i686
Interesting. On my notebook all is ok.
% uname -a
FreeBSD ... 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2
Is any possibility of broken locale?
Assuming that the locales on FreeBSD are the same or closely related to
the ones on Mac OS X, I would rather say that the BSD locales are
broken, because they don't actually support the Turkish case conversion
rules:
regression=# show lc_ctype;
lc_ctype
-
tr_TR.utf-8
(1 row)
regression=# select lower('SKIES');
lower
---
skies
(1 row)
regression=# select upper('skies');
upper
---
SKIES
(1 row)
Thus, the problem that the glibc locales appear to expose is masked here.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
