[HACKERS] Update to contrib/chkpass
After all these years of inactivity I don't think that I have commit
access any more so perhaps someone can review the attached update to
chkpass.c and commit it if it looks OK.
There are two major changes to the existing chkpass type:
1. It now handles MD5 as well as DES
2. It has a GUC variable to select which
Cheers.
--
D'Arcy J.M. Cain | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 788 2246 (DoD#0082)(eNTP) | what's for dinner.
IM: da...@vex.net, VoIP: sip:da...@druid.net
/*
* PostgreSQL type definitions for chkpass
* Written by D'Arcy J.M. Cain
* da...@druid.net
* http://www.druid.net/darcy/
*
* contrib/chkpass/chkpass.c
* best viewed with tabs set to 4
*/
#include "postgres.h"
#include
#include
#ifdef HAVE_CRYPT_H
#include
#endif
#include "fmgr.h"
#include "utils/builtins.h"
#include "utils/guc.h"
PG_MODULE_MAGIC;
/*
* This type encrypts its input unless the first character is a colon.
* The output is the encrypted form with a leading colon. The output
* format is designed to allow dump and reload operations to work as
* expected without doing special tricks.
*/
/*
* CHKPASS is now a variable-width type. The format for an md5-format
* password is $1$$ where the hash is always 22 characters
* when base-64 encoded. We allocate space for that, plus a leading :
* plus a trailing null.
*/
typedef struct varlena chkpass;
#define SALTLEN 8
#define CHKPASSLEN (VARHDRSZ + SALTLEN + 6 + 22)
/* controlled by the GUC chkpass.use_md5 */
static bool use_md5 = false;
/*
* Various forward declarations:
*/
Datum chkpass_in(PG_FUNCTION_ARGS);
Datum chkpass_out(PG_FUNCTION_ARGS);
Datum chkpass_rout(PG_FUNCTION_ARGS);
/* Only equal or not equal make sense */
Datum chkpass_eq(PG_FUNCTION_ARGS);
Datum chkpass_ne(PG_FUNCTION_ARGS);
/* This function checks that the password is a good one
* It's just a placeholder for now */
static int
verify_pass(const char *str)
{
return 0;
}
/*
* CHKPASS reader.
*/
PG_FUNCTION_INFO_V1(chkpass_in);
Datum
chkpass_in(PG_FUNCTION_ARGS)
{
char *str = PG_GETARG_CSTRING(0);
chkpass*result;
char mysalt[SALTLEN+6];
int i;
static char salt_chars[] =
"./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
result = (chkpass *) palloc(CHKPASSLEN);
/* special case to let us enter encrypted passwords */
if (*str == ':')
{
SET_VARSIZE(result, VARHDRSZ + strlen(str)-1);
memcpy(VARDATA(result), str+1, VARSIZE(result)-VARHDRSZ);
PG_RETURN_POINTER(result);
}
if (verify_pass(str) != 0)
ereport(ERROR,
(errcode(ERRCODE_DATA_EXCEPTION),
errmsg("password \"%s\" is weak", str)));
if (use_md5)
{
memcpy(mysalt, "$1$", 3);
for (i = 3; i < (3+SALTLEN); i++)
mysalt[i] = salt_chars[random() & 0x3f];
mysalt[3+SALTLEN] = '$';
mysalt[4+SALTLEN] = 0;
}
else
{
mysalt[0] = salt_chars[random() & 0x3f];
mysalt[1] = salt_chars[random() & 0x3f];
mysalt[2] = 0; /* technically the terminator is not necessary
* but I like to play safe */
}
strcpy(result->vl_dat, crypt(str, mysalt));
SET_VARSIZE(result, VARHDRSZ + strlen(result->vl_dat));
PG_RETURN_POINTER(result);
}
/*
* CHKPASS output function.
*/
/* common output code */
static char *
out(chkpass *password)
{
char *str;
size_t sz;
sz = VARSIZE(password) - VARHDRSZ;
str = palloc(sz + 1);
memcpy(str, VARDATA(password), sz);
str[sz] = 0;
return str;
}
PG_FUNCTION_INFO_V1(chkpass_out);
Datum
chkpass_out(PG_FUNCTION_ARGS)
{
char *str, *result;
str = out((chkpass *) PG_GETARG_POINTER(0));
result = (char *) palloc(strlen(str) + 2);
result[0] = ':';
strcpy(result + 1, str);
PG_RETURN_CSTRING(result);
}
/*
* special output function that doesn't output the colon
*/
PG_FUNCTION_INFO_V1(chkpass_rout);
Datum
chkpass_rout(PG_FUNCTION_ARGS)
{
char *str;
str = out((chkpass *) PG_GETARG_POINTER(0));
PG_RETURN_TEXT_P(cstring_to_text(str));
}
/*
* Boolean tests
*/
PG_FUNCTION_INFO_V1(chkpass_eq);
Datum
chkpass_eq(PG_FUNCTION_ARGS)
{
chkpass *a1 = (chkpass *) PG_GETARG_POINTER(0);
text *a2 = PG_GETARG_TEXT_P(1);
char *str;
char *t;
str = palloc(VARSIZE(a2)-VARHDRSZ+1);
memcpy(str, VARDATA(a2), VARSIZE(a2)-VARHDRSZ);
str[VARSIZE(a2)-VARHDRSZ] = 0;
t = crypt(str, VARDATA(a1));
PG_RETURN_BOOL(memcmp(VARDATA(a1), t, VARSIZE(a1)-VARHDRSZ) == 0);
}
PG_FUNCTION_INFO_V1(chkpass_ne);
Datum
chkpass_ne(PG_FUNCTION_ARGS)
{
chkpass *a1 = (chkpass *) PG_GETARG_POINTER(0);
text *a2 = (text *) PG_GETARG_TEXT_P(1);
char *str;
char *t;
str = palloc(VARSIZE(a2)-VARHDRSZ+1);
memcpy(str, VARDATA(a2), VARSIZE(a2)-VARHDRSZ);
str[VARSIZE(a2)-VARHDRSZ] = 0;
t = crypt(str, a1->vl_dat);
PG_RETURN_BOOL(memcmp(VARDATA(a1), t, VARSIZE(a1)-VARHDRSZ) != 0);
}
/* define
Re: [HACKERS] A minor correction in comment in heaptuple.c
On Tue, 18 Jun 2013 19:19:40 +0200 Andres Freund wrote: > The NULL refers to the *meaning* of the function (remember, it's > called slot_attisnull) . Which is to test whether an attribute is > null. Not to a C NULL. Actually, the comment is not for the function. It only describes the two lines that follow. In C the string "NULL" is commonly a reference to C's NULL value. Anyone reading C code can be excused for assuming that if it isn't otherwise clear. How about "Indicate that the attribute is NULL if out of range..."? Although, the more I think about it, the more I think that the comment is both confusing and superfluous. The code itself is much clearer. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 788 2246 (DoD#0082)(eNTP) | what's for dinner. IM: da...@vex.net, VOIP: sip:da...@vex.net -- 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] A minor correction in comment in heaptuple.c
On Tue, 18 Jun 2013 11:38:45 +0200 Andres Freund wrote: > > How about "check if attnum is out of range according to the tupdesc" > > instead? > > I can't follow. Minus the word 'NULL' - which carries meaning - your > suggested comment pretty much is the same as the existing comment > except that you use 'check' instead of 'return'. The difference is that I say what the purpose of the function is but don't say what it actually returns. The code itself does that. > Original: > /* >* return NULL if attnum is out of range according to the > tupdesc */ Obviously wrong so it should be changed. As for the exact wording, flip a coin and get the bikeshed painted. It's not all that critical. You could probably leave out the comment altogether. The code is pretty short and self explanatory. Perhaps the comment should explain why we don't test for negative numbers. I assume that that's an impossible situation. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 788 2246 (DoD#0082)(eNTP) | what's for dinner. IM: da...@vex.net, VOIP: sip:da...@vex.net -- 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] A minor correction in comment in heaptuple.c
On Tue, 18 Jun 2013 11:01:28 +0200 Andres Freund wrote: > > /* > > * return true if attnum is out of range according to the tupdesc > > */ > > if (attnum > tupleDesc->natts) > > return true; > > I think the comment is more meaningfull before the change since it > tells us how nonexisting columns are interpreted. I think that the comment is bad either way. Comments should explain the code, not repeat it. The above is not far removed from... return 5; /* return the number 5 */ How about "check if attnum is out of range according to the tupdesc" instead? -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 788 2246 (DoD#0082)(eNTP) | what's for dinner. IM: da...@vex.net, VOIP: sip:da...@vex.net -- 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] Feedback about Drupal SQL debugging
On Fri, 21 Aug 2009 18:22:41 +0200 Jean-Michel Pouré wrote: > I gathered some real examples here: Guidelines for writing MySQL and > PostgreSQL compliant SQL => http://drupal.org/node/14 > > This page gathers most frequent problems that Drupal users and > developers encounter when using PostgreSQL. > > I would be delighted to have your feedback. It looks to me like you could just reference SQL99 rather than mentioning PostgreSQL other than as an example of a standards compliant database engine. How would those constructs work in MS-SQL or Oracle? -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Maintenance Policy?
On Fri, 10 Jul 2009 19:51:31 -0400 Tom Lane wrote: > Josh Berkus writes: > > I'd suggest that we publish an official policy, with the following dates > > for "EOL": > > I have no objection to setting an EOL date for 7.4 now, but I think it > is premature to set EOL dates for later versions. I suppose the policy > you have in mind here (but are not spelling out) is that versions will > be EOL'd five years after release no matter what. I'm not convinced How about "five (or four or...) years after the next version is released?" That takes into account longer release schedules. That way we aren't guaranteeing support for a hard term for a release but rather that we will support it for a specified time from the date it is superceded by the next version. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] A deprecation policy
On Wed, 11 Feb 2009 09:47:25 +0200 Peter Eisentraut wrote: > 1. In release N, an interface is declared "obsolete", which means that > [...] > 2. In release N+1, obsolete interfaces are declared "deprecated", which I like the idea but aren't these two terms reversed? In fact, isn't "obsolete" your third stage? Certainly "obsolete" suggests that it can't be used any longer. I'm not sure what the second stage should be called in that case though. Also, does the progression through releases have to be absolute? Can something stay in "deprecated" for two releases if it is felt that people need more time? > Also, consider that we want to get in-place upgrade working, so > essential interfaces such as basic commands and configuration files > should at least be able to limp along after being moved to version N+1. Yes. > Altering semantics of log_filename without placeholder (under > discussion): Release 8.4: Declare current behavior obsolete. Release > 8.5: Deprecation warning. Release 8.6: Implement whatever new behavior > we like. But whatever works in 8.6 would also have to work in 8.4, right? We can't call something "deprecated" or "obsolete" without allowing the user to update their code/configuration right away. > I would also extend this system to removed configuration settings, e.g., > max_fsm_*. We should make these deprecated for one release, so (1) > configuration files can be upgraded without manual work (relevant to > in-place upgrade), and (2) users are alerted that their carefully > crafted configuration might need a review. As long as they can remove the item giving the warning right away. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Output filter for psql
On Wed, 28 Jan 2009 14:08:54 -0500 Andrew Dunstan wrote: > D'Arcy J.M. Cain wrote: > > I suppose we could define another line with options that we could > > define for meta information such as the border setting and the table > > name and whatever we define later. E.g: > > > > "table:person","border:3","funky:option with \":\"" > > Why do you want to add this extra information? psql doesn't output it > now, and IIRC your original proposal didn't do it either. It mentioned including meta information. I'm not sure that I really care if I get it but we may want it in general, if not now then later, and it would be something that would be extremely hard to retrofit. If we start out with just the table and perhaps the border setting we can always add more later if we find we need it. If we don't start with something then adding an extra line later will cause all sorts of heartache. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Output filter for psql
On Thu, 8 Jan 2009 17:22:04 -0500 "D'Arcy J.M. Cain" wrote: > So, I guess psql should pass XML to the user's filter and simply dump > its output to the screen. Is XML the best format? It would allow us > to pass meta information. For example, we could pass the border > setting so that the filter could change its output based on it. Pardon me while I argue with myself. :-) I wonder if XML isn't overkill for this. I think that we only need three pieces of information: - The column headings - The column types (in case the user wants it) - The data XML would be difficult from both the server as well as the user. Perhaps the simplest thing for both sides is simply CSV with an extra row for type. For example: person_id,person_name,person_email int,text,text 1,"darcy","D'Arcy Cain" 2,"tom","Tom Lane" 3,"bruce","Bruce Momjian" ...etc. The user could choose to ignore the second line if he doesn't need it. I suppose we could define another line with options that we could define for meta information such as the border setting and the table name and whatever we define later. E.g: "table:person","border:3","funky:option with \":\"" -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
On Mon, 12 Jan 2009 12:19:51 -0500 (EST) Bruce Momjian wrote: > Yep, that is my analysis as well. If you want a pretty ReST-like > output, that can be added later. Not if you use "border 3" for full ReST. I see nothing but pushback later if you try to make "border 4" give less than "border 3." Anyway, we have gone around the circle again and are no further ahead. As I see it, the original proposal was a logical extension to the border settings, it was extremely low impact on the code and some people would have found it useful. Unfortunately I made the tactical error of mentioning ReST early on and now it won't be accepted unless it is 100% ReST safe which it probably can never be and if it came close it would give butt ugly output in cases where it didn't need to. I guess my better option now is to push for the output filter for psql as I posted. It's a much bigger change and my simple filter for my simple needs would be way more complicated but there doesn't seem to be any hope down this road. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
So, what's happening. Is this discussion going into Limbo again for six months. It feels like the latest round of messages just went around the same circles as before. Let me summarize the different possibilities as I see them. 0. Drop this patch 1. Call it Rest and make it 100% compliant 2. Call it Rest-like 3. Call it simply border level 3 I don't think there are many supporting number 0 but... I think everyone agrees that number 1 is difficult, perhaps impossible, to achieve so its supporters probably drop into 0 or 2. Is there any chance we can narrow our choices here in order to focus discussions? Is it fair to say that our real choices are 0 and 3? Is there anyone who thinks that number 1 is achievable or that number 2 is a good precedent for the project? -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
On Fri, 9 Jan 2009 22:46:06 -0500 (EST) Greg Smith wrote: > On Fri, 9 Jan 2009, D'Arcy J.M. Cain wrote: > > >> "." is on the long list of characters to be escaped I sent out earlier. > > > > I tried escaping the '.' but it didn't change the behaviour. > > I did try that specific exapmle in Trac and it worked fine for me. Using > your test rig (which you gave the wrong URL to: > http://www.druid.net/darcy/rest.py ), I see this: > > I. Test -> 1. Test > I\. Test -> I. Test You are right. I can't recall the actual test I did but somehow I found a situation where escaping the period didn't DTRT. I know that it was in a table which is all we care about in this discussion but I just retested and got the same result as you. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
On Thu, 8 Jan 2009 18:45:43 -0500 (EST) Greg Smith wrote: > >> A. Einstein was a really smart dude. > > Which character in the above example would you escape. > > "." is on the long list of characters to be escaped I sent out earlier. > The parser looks for all sorts of enumeration syntaxes--A., I), (IV)--but > they all require some punctuation which makes those characters the ones to > focus on. I tried escaping the '.' but it didn't change the behaviour. > > I would suggest that if we want actual ReST-safe output we should create > > a "border = 4" setting. The code changes would be minimal. All we need > > to do is check for a value of 4 in addition to checking whether escaping > > is necessary. > > This seems like a reasonable spec to me. If you just want that general > format, you can get that and may very well end up with something that's > useful ReST anyway with the border=3 mode your existing patch implements. > As you demonstrated, there are several situations where a character you > think might do something special turns out to be ignored, with "\" being > the most likely to cause trouble. Enter the following into my test rig http://www.druid.darcy/rest.py: +++ | id | name | +++ | 8 | T'est | +++ | 9 | T*est | +++ | 10 | T\est | +++ | 11 | T\\est | +++ | 12 | T_est | +++ | 13 | T`est | +++ Notice that only the backslash needs to be escaped. However, if you just add the backslash it won't work because the table will be malformed. You need to widen every other field as well. As Tom has pointed out, ReST has problems beyond our implementation. People who use it are aware of these warts. Given that I really think that the cleanest solution is to just give them "border 3", don't mention ReST in the docs and have it happily work for 95% of the cases in a ReST processor. How about my other proposal under the "Output filter for psql" subject? That would let people create parsers as safe as they need them. I think that this proposal is still useful for those that need something quick and dirty though. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Output filter for psql
I have mentioned this as a side issue in another thread. I thought that it would be useful to start a separate thread for this. Perhaps this won't be so difficult to code and we can forget all about the ReST discussion. So, I guess psql should pass XML to the user's filter and simply dump its output to the screen. Is XML the best format? It would allow us to pass meta information. For example, we could pass the border setting so that the filter could change its output based on it. As for syntax, I'm not sure how difficult it would be to code but I was thinking something like this: \filter This would create a new format that can be set with pset. For example: \filter rest ~/my_filter ... \pset format rest I would imagine that the filter command would normally go into ~/.psqlrc since it would only be activated by the pset call. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
On Thu, 8 Jan 2009 13:51:44 -0500 (EST) Greg Smith wrote: > A. Einstein was a really > smart dude. > > Is parsed as two lines of text, while: > > A. Einstein was a really smart dude. > > Will be treated as a single-item list. That sort of ambiguity is quite a Yes, this is an issue. I'm not even sure how to fix it. > hindrance to machine-generation of ReST code. As the spec itself is very > loose, barring a deep read of the docutils code to figure out the rules > that exist only via the code implementation it seems to me the only robust > way around it is to just escape every special character. Which character in the above example would you escape. The problem with escaping is that someone may want this output for non-ReST purposes. They may not be making themselves known now but if we find a need later it will be hard if not impossible to make it available in a logical way. I would suggest that if we want actual ReST-safe output we should create a "border = 4" setting. The code changes would be minimal. All we need to do is check for a value of 4 in addition to checking whether escaping is necessary. I would still like to see some sort of plugin system for psql that would allow filters to be created for output. That would make this entire discussion moot as each of us could write whatever filter worked for them. That's a bigger deal though. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
On Thu, 8 Jan 2009 13:05:03 -0500 (EST) Bruce Momjian wrote: > So what would this show? > > \*escape* \*escape* > > Want to bet the second word it italics. Not in the Python implementation anyway. By the way, if you want to try something, http://www.druid.net/darcy/rest.py. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
On Thu, 8 Jan 2009 14:15:26 -0500 Michael Glaesemann wrote: > I think there may be confusion here betwixt ReST/RST and REST. > > REST: http://en.wikipedia.org/wiki/Representational_State_Transfer > ReST/RST: http://en.wikipedia.org/wiki/ReStructuredText Really? I don't think anyone in this conversation has been confused about what technology we are talking about. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
On Thu, 8 Jan 2009 12:08:06 -0500 (EST) Bruce Momjian wrote: > Right, so Tom says it isn't 100% ReST: > > http://archives.postgresql.org/pgsql-hackers/2008-08/msg01310.php Right but did you see the followup? http://archives.postgresql.org/pgsql-hackers/2008-08/msg01319.php -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
On Thu, 8 Jan 2009 12:30:52 -0300 Alvaro Herrera wrote: > > It is a great feature for people actually using ReST. However, the > > feature is really just a logical extension to the existing border > > attribute. > > Frankly I don't understand your position. You seem to be saying that > you want the logical extension to the border feature, because it's very > easy to write, but you don't want to go to all the trouble of writing an > actual rst output format -- I guess it's a lot more code. You don't > care that your new border format is not actually rst, because you have > no need for rst. In fact I wrote it because I do want it for ReST. When I first proposed it that was my sell. I received pushback because it was for too specific a purpose so I stepped back and showed that it was simply a logical extension that happened to work as ReST input. Now it seems that unless it is 100% ReST and documented as such it will be rejected. I'm feeling the ground shift under me. > Can I ask what is this logical extension of the border feature useful > for, keeping in mind that rst is not it? Perhaps some people will like this format better. I don't know. I want it for ReST. > Some people suggests that this is so close to rst that I should just use > it as if it were, and hand-edit the output for the rare cases where it > doesn't comply. I don't find this very compelling. The cases are so rare that I can't remember what they were if any. > Apparently the bottom line is that if it's not actual rst, it will get > rejected. OK, it's ReST. If there is a corner case that breaks ReST I am willing to treat it as a bug and fix it. Perhaps ReST should be the next level. That way people who just want the extra lines can get what they want and people who need 100% ReST can use "border 4" instead. That's if there is any difference of course. We could document "border 4" as ReST with no change to my code patch until we find some case where "border 3" breaks ReST. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
On Wed, 07 Jan 2009 18:12:58 -0500 Tom Lane wrote: > "D'Arcy J.M. Cain" writes: > > Bruce Momjian wrote: > >> As I remember, no actual patch was posted for this. > > > There was. I am attaching it again in case there were any changes > > to original files in the meantime. > > I think what Bruce meant to say is that this patch doesn't produce > 100% spec-compliant ReST, and that almost-ReST doesn't seem like a > good feature. It is a great feature for people actually using ReST. However, the feature is really just a logical extension to the existing border attribute. The fact that it is useful to people using ReST is just a happy coincidence. I don't think it should be referred to as the ReST feature. My patch does not mention ReST in the doc changes. By "logical extension" I mean this; 0: Underline column names with single line 1: Add lines between columns 2: Add table frame <<== Up to here already exists 3: Underline column names with double line and add line between rows It might be argued that '3' should be split between '3' and '4' since it is two changes but that's a minor matter. I can make that change to the patch if anyone sees any value to that. 3: Add line between rows 4: Use double line between header line and data -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
On Wed, 7 Jan 2009 17:22:38 -0500 (EST) Bruce Momjian wrote: > D'Arcy J.M. Cain wrote: > > So what have we decided about this suggestion. Should I submit the > > patch or just forget about it? So far some people like it and some > > people think that it is unneccessary. No one so far has suggested that > > it would harm the system or people's use of it. > > I have gone over the discussion about this issue. I think there is > interest in a ReST output format, but only a 100% ReST-compliant one. I > don't think anyone felt they wanted a ReST-like format just for > appearance sake. For that reason, I have added this TODO entry: Really? I thought that the opposite was true, that the argument against this change was that it was trying to be ReST. That's why I made a few posts arguing that while it mostly worked ReST, it was really just a logical extension of the existing border control. > As I remember, no actual patch was posted for this. There was. I am attaching it again in case there were any changes to original files in the meantime. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. pg_border.diff 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
Re: [HACKERS] The Axe list
On Sun, 12 Oct 2008 12:57:58 +0300
"Marko Kreen" <[EMAIL PROTECTED]> wrote:
> On 10/11/08, D'Arcy J.M. Cain <[EMAIL PROTECTED]> wrote:
> > + if (!random_initialized)
> > + {
> > + srandom((unsigned int) time(NULL));
> > + random_initialized = true;
> > + }
>
> This is bad idea, postgres already does srandom()
Is that new? I added that to my local version at one time because I
was getting the same salt every time I ran it.
> > -* but I like to play safe */
> > + mysalt[2] = 0; /* technically the terminator is not
> > +* necessary but I like to play safe */
> > strcpy(result->password, crypt(str, mysalt));
> > PG_RETURN_POINTER(result);
> > }
>
> Comment change only? Ok.
If that turns out to be the only change I won't bother.
> > + if ((result = (char *) palloc(16)) != NULL)
> > + {
> > + result[0] = ':';
> > + strcpy(result + 1, password->password);
> > + }
>
> AFAIK palloc() cannot return NULL?
Really? My program will simply come crashing down if there is a memory
problem without giving me a chance to clean up?
> > + if (!a1 || !a2)
> > + PG_RETURN_BOOL(0);
> > +
> > text_to_cstring_buffer(a2, str, sizeof(str));
> > PG_RETURN_BOOL(strcmp(a1->password, crypt(str, a1->password)) == 0);
> > }
> > @@ -154,6 +166,9 @@ chkpass_ne(PG_FUNCTION_ARGS)
> > text *a2 = PG_GETARG_TEXT_PP(1);
> > charstr[9];
> >
> > + if (!a1 || !a2)
> > + PG_RETURN_BOOL(0);
> > +
> > text_to_cstring_buffer(a2, str, sizeof(str));
> > PG_RETURN_BOOL(strcmp(a1->password, crypt(str, a1->password)) != 0);
> >
> > }
>
> The functions are already defined as STRICT, so unnecessary.
> Also returning non-NULL on NULL input seems to go against SQL style.
I'm a belt and suspenders guy. However, I agree that this is
unneccessary. So, I guess I just need to know, how long has PG been
doing srandom().
--
D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
--
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] The Axe list
On Sat, 11 Oct 2008 11:57:50 -0700
Josh Berkus <[EMAIL PROTECTED]> wrote:
> > However, if all it needs is a modern encryption scheme that's probably
> > an hour's work. The only reason that I haven't done so yet is because
> > I have no use case.
>
> Well, I had no use case either which is why I didn't propose updating
> it. I can certainly see having chkpass live on pgFoundry, though.
No need. I have places to put it up. I would like to make the
following changes for the CVS archives before it is removed though.
Any objections?
Index: chkpass.c
===
RCS file: /cvsroot/pgsql/contrib/chkpass/chkpass.c,v
retrieving revision 1.20
diff -u -p -u -r1.20 chkpass.c
--- chkpass.c 25 Mar 2008 22:42:41 - 1.20
+++ chkpass.c 11 Oct 2008 19:52:52 -
@@ -70,6 +70,7 @@ chkpass_in(PG_FUNCTION_ARGS)
char *str = PG_GETARG_CSTRING(0);
chkpass*result;
charmysalt[4];
+ static bool random_initialized = false;
static char salt_chars[] =
"./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
@@ -88,10 +89,16 @@ chkpass_in(PG_FUNCTION_ARGS)
result = (chkpass *) palloc(sizeof(chkpass));
+ if (!random_initialized)
+ {
+ srandom((unsigned int) time(NULL));
+ random_initialized = true;
+ }
+
mysalt[0] = salt_chars[random() & 0x3f];
mysalt[1] = salt_chars[random() & 0x3f];
- mysalt[2] = 0; /* technically the terminator is not
necessary
-* but I like to play safe */
+ mysalt[2] = 0; /* technically the terminator is not
+* necessary but I like to play safe */
strcpy(result->password, crypt(str, mysalt));
PG_RETURN_POINTER(result);
}
@@ -108,9 +115,11 @@ chkpass_out(PG_FUNCTION_ARGS)
chkpass*password = (chkpass *) PG_GETARG_POINTER(0);
char *result;
- result = (char *) palloc(16);
- result[0] = ':';
- strcpy(result + 1, password->password);
+ if ((result = (char *) palloc(16)) != NULL)
+ {
+ result[0] = ':';
+ strcpy(result + 1, password->password);
+ }
PG_RETURN_CSTRING(result);
}
@@ -142,6 +151,9 @@ chkpass_eq(PG_FUNCTION_ARGS)
text *a2 = PG_GETARG_TEXT_PP(1);
charstr[9];
+ if (!a1 || !a2)
+ PG_RETURN_BOOL(0);
+
text_to_cstring_buffer(a2, str, sizeof(str));
PG_RETURN_BOOL(strcmp(a1->password, crypt(str, a1->password)) == 0);
}
@@ -154,6 +166,9 @@ chkpass_ne(PG_FUNCTION_ARGS)
text *a2 = PG_GETARG_TEXT_PP(1);
charstr[9];
+ if (!a1 || !a2)
+ PG_RETURN_BOOL(0);
+
text_to_cstring_buffer(a2, str, sizeof(str));
PG_RETURN_BOOL(strcmp(a1->password, crypt(str, a1->password)) != 0);
}
--
D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
--
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] The Axe list
On Sat, 11 Oct 2008 16:07:31 +0200
Magnus Hagander <[EMAIL PROTECTED]> wrote:
> D'Arcy J.M. Cain wrote:
> > However, if all it needs is a modern encryption scheme that's probably
> > an hour's work. The only reason that I haven't done so yet is because
> > I have no use case. If I am storing encrypted passwords in a database
> > it's probably because I need to generate many password files from it.
> > As a result I need to keep it at the LCD. That's DES.
>
> Is there any reason for using this one over just using pgcrypto, which
> also gives you a whole lot more functionality?
Not quite the same. The pgcrypto module adds encryption functions but
chkpass adds an encrypted type. I suppose chkpass could be implemented
in terms of pgcrypto if one wished.
> > Which described functions are missing? I wouldn't mind having a
> > chance to clean it up before it is removed just in case someone else
> > wants to grab it from CVS later.
>
> /* This function checks that the password is a good one
> * It's just a placeholder for now */
> static int
> verify_pass(const char *str)
> {
> return 0;
> }
>
>
> It is documented that this is just a stub though.
Ah yes. I generally call external modules for that functionality as
they are much better at that than I could be in chkpass. I can upgrade
the external module when new ones appear rather than recompiling
chkpass each time.
--
D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
--
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] The Axe list
On Fri, 10 Oct 2008 16:28:29 -0700 Josh Berkus <[EMAIL PROTECTED]> wrote: > It's that time again! Purging antiquated contrib modules. > > chkpass: this module is incomplete and does not implement all functions > it describes. It's not really even useful as an Example since it uses > crypt() and not any modern encryption. And Darcy hasn't touched it in 6 > years. Well, I still use it a lot but I have it in my own CVS tree anyway so I won't miss it in contrib. However, if all it needs is a modern encryption scheme that's probably an hour's work. The only reason that I haven't done so yet is because I have no use case. If I am storing encrypted passwords in a database it's probably because I need to generate many password files from it. As a result I need to keep it at the LCD. That's DES. Which described functions are missing? I wouldn't mind having a chance to clean it up before it is removed just in case someone else wants to grab it from CVS later. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
So what have we decided about this suggestion. Should I submit the patch or just forget about it? So far some people like it and some people think that it is unneccessary. No one so far has suggested that it would harm the system or people's use of it. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] PostgreSQL future ideas
On Sat, 20 Sep 2008 13:47:10 +0300 Hannu Krosing <[EMAIL PROTECTED]> wrote: > On Fri, 2008-09-19 at 16:37 -0400, D'Arcy J.M. Cain wrote: > > I don't think that we should rush into any one language without > > checking the alternatives. Personally I think we should port everything > > to Intercal. > > My choice would be whitespace , see > http://en.wikipedia.org/wiki/Whitespace_(programming_language) Hey, we could write two modules into each file, one in Intercal and another in Whitespace. :-) -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] PostgreSQL future ideas
On Fri, 19 Sep 2008 20:57:36 +0100 "Dave Page" <[EMAIL PROTECTED]> wrote: > On Fri, Sep 19, 2008 at 8:54 PM, Gevik Babakhani <[EMAIL PROTECTED]> wrote: > > Has there been any idea to port PG to a more modern programming language > > like C++? Of course there are some minor obstacles like a new OO design, > > The plan is to start porting it to Java after the next release - > probably at the beginning of April. I don't think that we should rush into any one language without checking the alternatives. Personally I think we should port everything to Intercal. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Parsing of pg_hba.conf and authentication inconsistencies
On Fri, 12 Sep 2008 06:53:55 +1000 "Brendan Jurd" <[EMAIL PROTECTED]> wrote: > Josh has assigned your patch to me for an initial review. And me. > First up I'd like to say that this is a really nice upgrade. > Shielding a running server from reloading a bogus conf file makes a > whole lot of sense. Yes. > The patch applied cleanly to HEAD, compiled fine on amd64 gentoo and I had a small problem compiling. I'm not sure why it would be different for me. I run NetBSD -current. Here is the error: ../../../src/include/libpq/hba.h:51: error: field 'addr' has incomplete type I was able to fix this by adding the following line to hba.h: #include "libpq/pqcomm.h" /* needed for struct sockaddr_storage */ -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Noisy CVS updates
On Sun, 07 Sep 2008 10:39:25 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > > I assume that you are talking about conflicts. In fact, that's one of > > the main reasons for wanting a quiet update so that I can catch those > > right away when I am working on some files. I do an automatic update > > daily to keep current with the head. I don't do a "make distclean" > > first because I may be working on something and I want to keep the > > changes in the tree to try stuff and report patches against HEAD. > > Huh? distclean does not remove any source-code changes, only derived > files. Sorry, I was unclear. I meant that I might still be working on some source code changes and I didn't want to do a distclean every morning and then have to rebuild the tree in order to be able to work on my changes again. I use CVS in enough projects to understand how it works. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Noisy CVS updates
On Sun, 07 Sep 2008 03:39:39 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes: > > ...etc. Would it be OK if I went in and added .cvsignore files to keep > > the noise level down? > > Uh, no, at least not before you've explained why you get those messages > and others don't. I didn't know that I am the only one. Am I? > (Personally, I never do "cvs update" without "make distclean" first; > there are too many other ways to get screwed by updating a live build > tree.) I assume that you are talking about conflicts. In fact, that's one of the main reasons for wanting a quiet update so that I can catch those right away when I am working on some files. I do an automatic update daily to keep current with the head. I don't do a "make distclean" first because I may be working on something and I want to keep the changes in the tree to try stuff and report patches against HEAD. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Noisy CVS updates
When I build from CVS I wind up with this in my CVS update email in the morning: ? GNUmakefile ? config.log ? config.status ? src/Makefile.global ? src/backend/postgres ? src/backend/bootstrap/bootstrap_tokens.h ? src/backend/catalog/postgres.bki ? src/backend/catalog/postgres.description ? src/backend/catalog/postgres.shdescription ? src/backend/parser/parse.h ? src/backend/snowball/snowball_create.sql ...etc. Would it be OK if I went in and added .cvsignore files to keep the noise level down? I guess I could have my daily script filter them out but there may be times when there really is an unexpected file and I want to follow up on it. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
On Fri, 29 Aug 2008 18:07:36 +0100 Gregory Stark <[EMAIL PROTECTED]> wrote: > I'm starting to think D'Arcy's on the right track here. Is that the train coming? :-) > Keep in mind the use case here is as Alvaro says, just a user convenience > thing. It's not meant for file dumps and loads. If we're going to display an > ascii table we may as well use the same formatting as other tools so it can be > copy/pasted in. Well, Tom makes a good point about trying to make it fit one specific markup language perfectly. The important thing here is that it stand on its own as a nice display. > Given that it's just a user convenience thing then I'm not sure the escaping > is necessarily a big deal. If the user happens to have any backslashes in > their data they can always stick a replace() call in their SQL. Perhaps we > should prove a rest_escape() function for that purpose. I think that a setting is just a lot cleaner. Remember, the use case here is that someone wants to do an ad-hoc query and drop it into some other tool. A simple "SELECT * FROM table" should work. > I wonder if it's worth keeping two variants at all really. Why not just make > psql's native table formatting exactly ReST? Is there any part of it that we > don't like as much as our existing tables? No, Tom is right. This should not be a ReST format. For one thing, the user may just want the extra lines and any escaping/formatting would get in their way. And what do you mean by "native?" Border 0? Border 1? Border 2? I think that "principle of least surprise" demands that these not change on a user. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
On Fri, 29 Aug 2008 06:55:45 -0400 "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote: > On Fri, 29 Aug 2008 01:29:14 -0400 > I think that your scan may have been a bit too cursory. Those > characters, while significant in ReST, only matter when used in very > specific ways. The following works just fine in my ReST application. > > ++---+ > | id | name | > ++===+ > | 8 | T'est | > ++---+ > | 9 | T*est | > ++---+ > | 10 | T\est | > ++---+ Oops. I was wrong about this one. The backslash needs to be escaped. It also means expanding the other rows to match so this is the corner case. In fact, for one or two backslashes you can double it and remove the space at the start and/or end which is not so bad. I'm surprised that we don't have a general option to escape special characters. Perhaps that's the next small enhancement. darcy=# \pset escape \ For example. The general output filter I suggested previously could also deal with that, of course. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
On Fri, 29 Aug 2008 01:29:14 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > Hmm ... the patch works for data that contains no backslashes, > asterisks, backquotes, vertical bars, nor underscores. Nor perhaps > other special characters that I might've missed in one cursory scan of > the ReST spec. I'm not sure which side of this should be considered a > "corner case"; but I am quite certain that anyone trying to pass data > into a ReST-reading application will soon be dissatisfied with this > patch. I think that your scan may have been a bit too cursory. Those characters, while significant in ReST, only matter when used in very specific ways. The following works just fine in my ReST application. ++---+ | id | name | ++===+ | 8 | T'est | ++---+ | 9 | T*est | ++---+ | 10 | T\est | ++---+ | 11 | T`est | ++-------+ | 12 | T_est | ++---+ -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
On Sun, 24 Aug 2008 13:22:38 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > > I suppose it is my fault for mentioning ReST. That was the reason I > > looked into this but that is not what the final proposal is. > > Well, if you can't just paste your output into ReST without having to > hand-munge it afterwards, then ISTM the argument for having this > additional bit of complexity in our printing routines really falls flat. But Tom, you are still treating this as a ReST option. Please, pretend that I never mentioned ReST. Consider this simply as a proposal to make a logical extension to the "border [0|1|2]" setting. If you were going to extend border to 3, what would you do? Adding extra row dividers and turning dashes into equal signs for the existing row divider seems pretty logical on its own without referencing any external formats. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
On Sun, 24 Aug 2008 09:16:43 -0400 "Merlin Moncure" <[EMAIL PROTECTED]> wrote: > Personally I think it's rather nice to be able to have some extra > flexibility in how psql prints out data. Maybe, instead of the dry > and uninformative 'border 2', there could be a set of ouput control > options. Maybe I want the text aligned but with no border for > example. You mean like "\pset border 0" does? Personally I would love to see user defined display outputs for full flexibility. Since we already have XML I would suggest using that as a base and allow filters to process it before output. That's a much larger job though. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
On Sat, 23 Aug 2008 14:57:50 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > Also, having now looked at the proposed patch, it seems clear that it > isn't addressing the issue of quoting/escaping at all; so I wonder how > this can be considered to be a safely machine-readable format. It's not a machine readable format. It is a simple display with more border lines. Just like "border 2" is like "border 1" with more border lines. I'm just following the progression. > In particular, the output seems to me to not even approximate the rules > laid down at > http://docutils.sourceforge.net/docs/user/rst/quickref.html And there is no reason that it should. > So, quite aside from the question of whether we care to support ReST, > my opinion is that this patch fails to do so, and a significantly more > invasive patch would be needed to do it. I suppose it is my fault for mentioning ReST. That was the reason I looked into this but that is not what the final proposal is. I too would argue against making a munged output just to match one formatting scheme. If I do a query and I need to modify it manually when I use it in *any* third party program that's my personal issue. If "border 3" happens to get me closer to my format that's great but it has to stand on its own merit. I think that this proopsal does. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
On Sat, 23 Aug 2008 14:42:57 -0400 Andrew Dunstan <[EMAIL PROTECTED]> wrote: > In general I think I prefer machine readable formats to be produces by > the backend so they are available through all clients, not just psql. What do you mean by "machine readable?" XML? > That said, this has sufficiently low impact that I'm not going to be > vastly upset if we let it through. > > I think we should probably confine ourselves to output formats that are > in very wide use or we'll be supporting a vast multitude. CSV and XML > both qualify here - not sure that ReST does. It isn't ReST. It just happens that this very simple and logical progression of the border setting works for ReST. The display stands on its own. This is not true of machine readable formats like XML. I guess the question is, why border 2? Border 1 seems to be enough. In fact border 0 has everything we absolutely need. Why have any borders? -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
On Thu, 21 Aug 2008 21:04:07 -0400 "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote: > > There's still the question of whether this covers any needs that aren't > > met just as well by XML or CSV output formats. > > Well, we could remove all the display formats except XML. After all, > it can always be converted to any other format. Of course we wouldn't > do that. User convenience is all I'm thinking of. Well, Tom has raised a question about its need and Asko has questioned whether it should be under a different setting but so far no one has outright rejected the proposal. Does anyone else have an opinion? I am attaching a patch for further review. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. border_change.diff 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
Re: [HACKERS] Feeding results back into select
On Sat, 23 Aug 2008 14:04:30 +0400
Teodor Sigaev <[EMAIL PROTECTED]> wrote:
> >> select 'a'=>'b';
> >>?column?
> >> --
> >>"a"=>"b"
> "a"=>"b" is a value of hstore type, so query should be:
> select '"a"=>"b"'::hstore;
Of course. Now that I understand it's blindingly obvious that the
double quotes above are part of the string and the insert would be;
INSERT INTO table (hfield) VALUES ('"a"=>"b"');
> " character was chosen to simplify escaping,
To prevent;
INSERT INTO table (hfield) VALUES ('''a''=>''b''');
I guess my brain was pointed elsewhere when I asked. Thanks for not
treating me like an idiot. :-)
--
D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
--
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] Feeding results back into select (was: proposal sql: labeled function params)
On Sat, 23 Aug 2008 00:03:16 +0400 Teodor Sigaev <[EMAIL PROTECTED]> wrote: > select 'a'=>'b'; >?column? > -- >"a"=>"b" Branching the topic, I have a question about this. I haven't studied hstore extensively but this seems like a problem on it's face. Shouldn't you be able to take the result of a select and pass it back to a select? I mean, what happens if you do this? select "a"=>"b"; I suspect that you would get "ERROR: column "a" does not exist" if you do that. What happens when you try to restore a dump? I ran into a similar issue with my chkpass type (see contrib) where the string inserted into the field is stored encrypted with functions to test for equality basically like the Unix password model works. If I just displayed raw strings then a dump and reload would have trashed all the passwords by re-encrypting them. What I did was to make a special case on input. If the string started with ':' then I strip that character and insert the string unchanged. Then I changed the output to prepend the ':'. Now dump and reload work. Just curious. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
On Fri, 22 Aug 2008 08:23:01 +0200 Martijn van Oosterhout <[EMAIL PROTECTED]> wrote: > On Thu, Aug 21, 2008 at 11:18:24PM -0400, D'Arcy J.M. Cain wrote: > > ReST is nice because it's almost plain text. In fact, a ReST document > > source can easily be read raw. > > I presume by ReST you mean this: > http://docutils.sourceforge.net/rst.html Yes. See the original message in this thread. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
On Thu, 21 Aug 2008 21:19:58 -0400 Alvaro Herrera <[EMAIL PROTECTED]> wrote: > Tom Lane escribió: > > There's still the question of whether this covers any needs that aren't > > met just as well by XML or CSV output formats. > > I think it does -- I used to use the Latex output format for easy cut'n > pasting. ReST sounds like it serves the same purpose. If I had had to > use conversion to XML, it would have been rather painful. ReST is nice because it's almost plain text. In fact, a ReST document source can easily be read raw. > What I wonder is whether this should be a border setting or a format > setting. I don't see it as a format for two reasons. First, it isn't really a different format. It's just the same format as "border 2" with a few extra lines. Second, and following from the first, it's such a logical progression from "border 0" to the proposed "border 3" that that syntax makes more sense. In fact, the guide is inches away from describing this behaviour already. Besides, making it a border option adds 12 lines to the code, 5 of which are blank. I wouldn't want to think about the changes if it was a different setting. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
On Thu, 21 Aug 2008 20:36:51 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes: > > No, I meant that one would do any ad hoc query and cut and paste the > > output directly into a tracking tool that supports ReST. > > There's still the question of whether this covers any needs that aren't > met just as well by XML or CSV output formats. Well, we could remove all the display formats except XML. After all, it can always be converted to any other format. Of course we wouldn't do that. User convenience is all I'm thinking of. What do you think of the idea of allowing user defined display functions? Of course, that's a much bigger job. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
On Thu, 21 Aug 2008 23:22:28 +0300 "Asko Oja" <[EMAIL PROTECTED]> wrote: > The idea would be to use psql as backend for some other system? > Or what do you mean by fed directly? No, I meant that one would do any ad hoc query and cut and paste the output directly into a tracking tool that supports ReST. As I explained in another message though, this is a nice side effect for me and is the reason that I have an interest in coding it but it really is a logical extension of what we have anyway. Look how simple the documentation change would be. If you left out the extra example it's a one line difference. Index: src/sgml/ref/psql-ref.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v retrieving revision 1.209 diff -u -p -u -r1.209 psql-ref.sgml --- src/sgml/ref/psql-ref.sgml 3 Jul 2008 03:37:16 - 1.209 +++ src/sgml/ref/psql-ref.sgml 21 Aug 2008 20:31:24 - @@ -1570,7 +1570,7 @@ lo_import 152801 HTML mode, this will translate directly into the border=... attribute, in the others only values 0 (no border), 1 (internal dividing lines), - and 2 (table frame) make sense. + 2 (table frame) and 3 (individual cells) make sense. @@ -2973,6 +2973,22 @@ [EMAIL PROTECTED] testdb=> S +---++ (4 rows) [EMAIL PROTECTED] testdb=> \pset border 3 +Border style is 3. [EMAIL PROTECTED] testdb=> SELECT * FROM my_table; ++---++ +| first | second | ++===++ +| 1 | one| ++---++ +| 2 | two| ++---++ +| 3 | three | ++---++ +| 4 | four | ++---++ +(4 rows) + [EMAIL PROTECTED] testdb=> \pset border 0 Border style is 0. [EMAIL PROTECTED] testdb=> SELECT * FROM my_table; -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] Proposal: new border setting in psql
On Thu, 21 Aug 2008 15:03:23 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes: > > I would like to propose a new border setting. > > That code is horrendously overcomplicated and unreadable already :-( > I'm not too eager to add more variants to it. Actually, I already made the code changes and they were surprisingly simple. > > The reason for this is to allow the output to be fed directly into any > > system using Restructured text as described in > > http://docutils.sourceforge.net/docs/user/rst/quickref.html. > > Is that *really* going to work? What about quoting/escaping > conventions? ReST is pretty good with that stuff. > Also, how many of those "any systems" actually exist? Markup > conventions are a dime a dozen. That I can't say. My impression was that it was reasonably well known. However, while ReST was *my* reason for proposing this it was also important to me that the format stand by itself. I think it does. It also follows the documentation in that it is an extension to border 2 but with more borders, just like border 2 is more than border 1, etc. It's a consistent progression. > On the whole I think it ought to be sufficient to support XML output > for people who want easily-machine-readable query output. Perhaps. The problem is that it still means running it through an external program. That's fine for scripted processes but not for ad hoc queries. Perhaps what we really need is the ability for users to install their own formatting functions. After all, we can define everything else. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Proposal: new border setting in psql
Here is a simple select output. darcy=# select title_id, title_name from title; title_id | title_name --+ 2 | Mrs 3 | Ms 4 | Miss (3 rows) Now I change the border. darcy=# \pset border 2 Border style is 2. darcy=# select title_id, title_name from title; +--++ | title_id | title_name | +--++ |2 | Mrs| |3 | Ms | |4 | Miss | +--++ (3 rows) I would like to propose a new border setting. darcy=# \pset border 3 Border style is 3. darcy=# select title_id, title_name from title; +--++ | title_id | title_name | +==++ |2 | Mrs| +--++ |3 | Ms | +--++ |4 | Miss | +--++ (3 rows) The reason for this is to allow the output to be fed directly into any system using Restructured text as described in http://docutils.sourceforge.net/docs/user/rst/quickref.html. If there is any interest I will submit patches for code and documentation. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] modules
On Sat, 05 Apr 2008 09:18:07 +0200 PFC <[EMAIL PROTECTED]> wrote: > But of course you need the ISP to do it for you if you are not > superuser. > Some will bother to run a few commands for a user, some won't... Right. I encourage my competitors to do nothing for their clients. I will continue to help mine any way I can. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] modules
On Sat, 05 Apr 2008 02:17:10 +0100 Gregory Stark <[EMAIL PROTECTED]> wrote: > I was inclined to dismiss it myself but I think the point that's come up here > is interesting. The ISP has to not just install an RPM or type make install in > some source tree -- but actually log into each customer's database and run an > SQL script. That does seem like more work and more risk than a lot of ISPs > will be willing to take on. Why wouldn't you just run it against template1 so that it is available in every database created after that? -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] modules
On Fri, 4 Apr 2008 20:22:51 -0400 Aidan Van Dyk <[EMAIL PROTECTED]> wrote: > Unfortunately, the current state really does seem to mean that the > "feature of modularity" really is the kiss of death, since things are > actively pushed out from core to be modular projects, making them > unusable for most people... Is there anything but anecdotal evidence for this statement? I mean, yes, some ISPs will make life hard for their users and some http://www.Vex.Net/"; /> will work with their clients to deliver what they need. Besides, most users of PostgreSQL are probably enterprise users or users running off of their own systems who have all the access they need. How big is this "problem" really? -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] modules
On Thu, 03 Apr 2008 13:06:25 -0400 Andrew Dunstan <[EMAIL PROTECTED]> wrote: > D'Arcy J.M. Cain wrote: > > In fact, this may be the way to deprecate contrib. Start building > > modules and move the contrib packages to it one at a time. That way > > people using contrib have some time to switch and we can point people > > to modules if they are just starting out. > > > > Is there support for this idea? I would like to start exploring this > > if so. > > No. I don't want to deprecate it, I want to get rid of it, lock, stock > and barrel. If you think that we need more than renaming then we can > discuss it, but I don't want a long death, I want one that is certain > and swift. Well, OK, but given that this is a huge public project with lots of users expecting things to be in certain places, how fast do you think we could make such a change. It seems to me that we are going to have to make things look the same for some time at least otherwise we are going to have lots of complaints. How swift is swift? To me, swift means add the alternate functionality to the next release and remove the old in the release after. Do you see things happening any faster? -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] modules
On Thu, 03 Apr 2008 09:31:01 -0700 Ron Mayer <[EMAIL PROTECTED]> wrote: > D'Arcy J.M. Cain wrote: > > Check out NetBSD pkgsrc as a model. It is very flexible. One nice > > thing would be the ability to specify where the packages are rather > > than always insisting that they be on pgfoundry. > > Yup - a feature shared by RubyGems: >gem install rails ?source http://gems.rubyonrails.org Yes but what I am suggesting goes beyond that. My idea is that there is a modules directory that contains a file for each installable module. This file would contain all the information about the module such as name, version, where to get the actual package, an MD5 checksum of the package, minimum and maximum PostgreSQL versions required, etc. Naturally we should allow for people to define their own local packages as well. In fact, this may be the way to deprecate contrib. Start building modules and move the contrib packages to it one at a time. That way people using contrib have some time to switch and we can point people to modules if they are just starting out. Is there support for this idea? I would like to start exploring this if so. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] modules
On Thu, 3 Apr 2008 09:41:57 -0700 "Joshua D. Drake" <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Thu, 3 Apr 2008 12:35:31 -0400 > "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote: > > > On Thu, 3 Apr 2008 13:54:11 - > > "Greg Sabino Mullane" <[EMAIL PROTECTED]> wrote: > > > Right now contrib is a real catch-all of various things; it would > > > be nice to categorize them somehow. And by categorize, I > > > emphatically do NOT mean move to pgfoundry, which is pretty much a > > > kiss of death. > > Pgfoundry is not a kiss of death except that you spread falsehoods like > that. PGfoundry is a very alive project that is constantly adding > content and has continuing and very active projects. Eep! Careful with attributions. There is not a single word of mine in what you included. I know it technically says that but since your comments were directed at Greg you really should have replied to his email and not to mine that included his. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] modules
On Thu, 3 Apr 2008 13:54:11 - "Greg Sabino Mullane" <[EMAIL PROTECTED]> wrote: > Right now contrib is a real catch-all of various things; it would be nice to > categorize them somehow. And by categorize, I emphatically do NOT mean > move to pgfoundry, which is pretty much a kiss of death. Yes! I have plenty of FTP servers to put up my own open source projects. It would annoy me if I was forced to use someone else's development environment. Whatever we do should allow for packages to be picked up from anywhere. We can use MD5 checksums to assure users that no one has changed the file since it was tested and packaged. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- 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] modules
On Wed, 02 Apr 2008 20:15:49 -0400 Andrew Dunstan <[EMAIL PROTECTED]> wrote: > > I think it'd be especially cool if one could one-day have a command > > > > pg_install_module [modulename] -d [databasename] > > > > and it would magically get (or verify that it had) the latest > > version from pgfoundry; compile it (if needed) and install it > > in the specified database. > > > > The closest analogy to what I'm thinking is the perl CPAN or ruby gems. Check out NetBSD pkgsrc as a model. It is very flexible. One nice thing would be the ability to specify where the packages are rather than always insisting that they be on pgfoundry. > Yes, and the CPAN analogy that has been in several minds, but it only > goes so far. Perl and Ruby are languages - Postgres is a very different > animal. So the underlying struture needs to keep that in mind. Overall though I don't think that what is being installed to changes much. The basics remain the same - define the package with latest version, download if necessary,check that the source package is the correct, tested one, build, install, register. There are some special considerations for PostgreSQL but I think that the fact that there are unsolved problems shouldn't stop us from solving them. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [COMMITTERS] pgsql: Link postgres from all object files at once, to avoid the
On Mon, 25 Feb 2008 21:39:27 -0500 Tom Lane <[EMAIL PROTECTED]> wrote: > Hm, just noticed another little annoyance: CVS is going to complain about > the objfiles.txt files unless we add a .cvsignore entry to every last > subdirectory of the backend. That seems like a lot of maintenance > tedium. I wonder if there's another way, such as using a file name that > CVS is already programmed to ignore. Why not just add it to CVSROOT/cvsignore? -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Including PL/PgSQL by default
On Fri, 22 Feb 2008 07:37:55 + "Dave Page" <[EMAIL PROTECTED]> wrote: > I know I'm gonna regret wading in on this, but in my mind this is akin > to one of the arguments for including tsearch in the core server - > namely that too many brain dead hosting providers won't add a contrib > module or anything else in a customer's database because they don't So their clients will go somewhere http://www.Vex.Net/"; /> that does understand what they are installing and can support their users properly. How far are we supposed to go to support the clueless? > understand that just because it's not there by default doesn't mean > it's in any way second rate. Including pl/pgsql in template1 will help > those folks who forwhatever reason use such providers, whilst more > savvy providers can easily disable it post-initdb if thats what they > want to do. And the first time someone uses pl/pgsql to do harm, even if it is due to their mis-configuration, who gets blamed? -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Including PL/PgSQL by default
On Thu, 21 Feb 2008 14:14:48 -0500 Andrew Sullivan <[EMAIL PROTECTED]> wrote: > On Thu, Feb 21, 2008 at 10:43:27AM -0800, Joshua D. Drake wrote: > > often. It is poor implementation and proof that the theoretical > > security implications that are being brought up in this thread are far > > from the practical reality. > > "We have this hole over here for historical reasons, so let's maybe open a > new one over there"? Besides, proof that it would do no extra harm is hardly a strong argumet for including it. Given how easy it is to add it to any DB that needs it, I fail to see why we should add it by default. Personally I would like to see more things removed from PG and have them added as modules when required. Of course, we would need a proper module system first. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(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: [HACKERS] Permanent settings
On Thu, 21 Feb 2008 10:30:00 +0100 Magnus Hagander <[EMAIL PROTECTED]> wrote: > Do you know of any cross-platform tool that is capable of dealing with the > PostgreSQL configuration file in a context sensitive manner? Meaning that > it doesn't just treat it as a big file, but you can actually do "for all > these 32 servers, change work_mem to 2Mb"? If so, I'd like to know which > one beause I could *raelly* use that one right now. If it was me I would create a database that served variables and a portable script - Python for me but Perl would probably work too - that read variables from the database and plugged them into a basic template. That way you can make localized changes to specific servers by changing the database or global changes by changing the template. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Password policy
On Wed, 16 Jan 2008 08:32:12 -0500 Andrew Dunstan <[EMAIL PROTECTED]> wrote: > >> I need to set a basic password policy for accounts but I don't see any > > Look at my chkpass type in contrib. There is a function to verify the > > password. It is just a placeholder now but you can modify it to do all > > your checking. > > I assumed he was asking about Postgres level passwords rather than > passwords maintained by an application. chkpass is only for the latter. Could be. I saw "accounts" and thought Unix shell or ISP accounts. > ( Slightly OT - chkpass uses crypt(). Maybe that should be upgraded to > use md5 or some more modern hashing function. ) Yes, I have said many times that other encryption types could easily be dropped in. It could even be changed to handle either as long as there was some way to set the default. However, these things haven't yet been a requirement for me so I have not bothered yet. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Password policy
On Tue, 15 Jan 2008 16:11:16 -0600 "Roberts, Jon" <[EMAIL PROTECTED]> wrote: > I need to set a basic password policy for accounts but I don't see any > documentation on how to do it. I'm assuming there is a way to do this, > maybe even with a trigger. > > The policy would be something like this: > 1. Must contain letters and numbers > 2. Must be at least 8 characters long > 3. Must contain one special character (#,@,$,%,!, etc) > 4. Password (not the account) must expire after 90 days > 5. Must warn users 10 days before the expire to change the password Look at my chkpass type in contrib. There is a function to verify the password. It is just a placeholder now but you can modify it to do all your checking. Policies 4 & 5 may require further work either in the chkpass type or with a separate field. Details are hard to suggest as I can think of three or four methods right away but it all depends on more detailed requirements to determine the best one. Non-database related suggestion: Reconsider 4 & 5 anyway. Forcing people to change their passwords all the time is less secure, not more. In those situations you tend to find a lot more passwords on post-it notes and in clear text files. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Spoofing as the postmaster
On Sat, 29 Dec 2007 10:38:13 -0500 Andrew Dunstan <[EMAIL PROTECTED]> wrote: > > > D'Arcy J.M. Cain wrote: > > - 1: How does the client assure that the postmaster is legit > > - 2: How does the postmaster assure that the client is legit > > And neither answers the original problem: Which seems to have been lost in the noise. > 3. How can the sysadmin prevent a malicious local user from hijacking > the sockets if the postmaster isn't running? A better way of stating it for sure. > Prevention is much more valuable than ex post detection, IMNSHO. > > Probably the first answer is not to run postgres on a machine with > untrusted users, but that's not always possible. Maybe we can't find a > simple cross-platform answer, but that doesn't mean we should not look > at platform-specific answers, at least for documentation. Yes, that's what I said at the start of this discussion. If you don't trust the users with actual access to the box, the rest of this is pretty much academic. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Spoofing as the postmaster
On Sat, 29 Dec 2007 12:45:26 +0100 Magnus Hagander <[EMAIL PROTECTED]> wrote: > That is exactly my point. The server can never know if the client has > actually verified anything. It can provide the client with the *means* > to verify things, but it can't enforce it. I know this is probably obvious to most people in this discussion and I don't mean to impugn Magnus just because I am latching onto his message to make this point but I suspect that this discussion would go a lot smoother if it branches into two completely different discussions about two completely different issues; - 1: How does the client assure that the postmaster is legit - 2: How does the postmaster assure that the client is legit Does anyone think that there is one answer to both? -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Spoofing as the postmaster
On Sun, 23 Dec 2007 07:57:07 + Gregory Stark <[EMAIL PROTECTED]> wrote: > "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes: > > It's generally a bad idea to put your database on a public server > > anyway but if you do you should definitely disable unix domain sockets > > and connect over TCP to localhost. That has been our rule for years. > > That seems like a terrible idea. At least while you're dealing with unix > domain sockets you know there's no way a remote user could possibly interfere > with or sniff your data. As soon as you're dealing with TCP it's a whole new > ballgame. Are you suggesting that you would have Unix domain sockets only? I have never seen this scenario other than dedicated db/web/etc servers that don't have public users so that's not an issue anyway. Once you are allowing untrusted users access you are probably allowing remote access as well. Two different models and two different security requirements n'est pas? Certainly the scenario where you have untrusted users on a server and require that only logged in users can access the database is possible. I have just never seen it and suspect that it is rare. Since I am suggesting that this is really a documentation and warning issue then this possibility can be examined and discussed in the documentation. > X famously had a problem on many OSes where you could spoof the first packet > (and if you could predict sequence numbers more than that) of a connection > allegedly coming from 127.0.0.1. (it helped that a message to open up > connections from anywhere fit in one packet...) Modern OSes include network > filters to block such spoofs but it's one more thing you're counting on. Well, yes, I do count on the OS being reasonably modern and secure. I don't think that that is an unreasonable expectation. > Also brought into place are things like forged RST packets, routing table > attacks, and on and on. If this is an issue then don't allow remote access. In this case Unix domain sockets only make sense. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Spoofing as the postmaster
On Sat, 22 Dec 2007 09:25:05 -0500 (EST) Bruce Momjian <[EMAIL PROTECTED]> wrote: > I think at a minimum we need to add documentation that states if you > don't trust the local users on the postmaster server you should: > > o create unix domain socket files in a non-world-writable > directory > o require SSL server certificates for TCP connections > > Ideas? It's generally a bad idea to put your database on a public server anyway but if you do you should definitely disable unix domain sockets and connect over TCP to localhost. That has been our rule for years. It's certainly a corner case. I would think that warnings, perhaps in the config file itself, would be sufficient. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: Add regression tests for MONEY type.
On Sat, 24 Nov 2007 17:22:35 -0300 Alvaro Herrera <[EMAIL PROTECTED]> wrote: > D'Arcy J.M. Cain wrote: > > Log Message: > > --- > > Add regression tests for MONEY type. > > This has broken the buildfarm ... It worked here. Can you send me the error output. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] type money causes unrestorable dump
On Sun, 04 Nov 2007 20:38:11 -0500 Tom Lane <[EMAIL PROTECTED]> wrote: > "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes: > > Hmm. I think I like Tom's version better. However, since my primary > > goal here is to remove the deprecation I will let you guys duke it out > > over the additional clause. :-) > > Just pick the wording you like and commit it; we've spent more than > enough time on this already. OK. I can't seem to connect at the moment but I will commit tomorrow morning if not before. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] type money causes unrestorable dump
On Sun, 4 Nov 2007 17:24:10 -0500 (EST) Bruce Momjian <[EMAIL PROTECTED]> wrote: > D'Arcy J.M. Cain wrote: > > + > > +Since the output of this data type is locale-sensitive, it may not > > +work to load money data into a database that has a different > > +setting of lc_monetary. To avoid problems, before > > +restoring a dump make sure lc_monetary has the same or > > +equivalent value as in the database that was dumped. > > + > > + > > How about: > > > +restoring a dump make sure lc_monetary has a value similar > > +to the dumped database. Hmm. I think I like Tom's version better. However, since my primary goal here is to remove the deprecation I will let you guys duke it out over the additional clause. :-) -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] type money causes unrestorable dump
On Sat, 03 Nov 2007 15:47:40 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > Greg's objection caused me to rethink that. Doing it would be a problem > when transporting dump files across platforms: what if the appropriate > locale name is spelled differently on the new machine? We should > probably leave it in the user's hands to get this right. So the added > text could be used as I suggested, or tweaked to say that you must set > lc_monetary to something equivalent to the prior setting. OK, how is this? Index: doc/src/sgml/datatype.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v retrieving revision 1.211 diff -u -p -u -r1.211 datatype.sgml --- doc/src/sgml/datatype.sgml 21 Oct 2007 20:04:37 - 1.211 +++ doc/src/sgml/datatype.sgml 4 Nov 2007 17:09:03 - @@ -834,14 +834,6 @@ ALTER SEQUENCE Monetary Types - - - The money type is deprecated. Use - numeric or decimal instead, in - combination with the to_char function. - - - The money type stores a currency amount with a fixed fractional precision; see Monetary Types -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] type money causes unrestorable dump
On Sat, 03 Nov 2007 14:39:48 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes: > > I never received a response on this. Here is the full diff with the > > above change. Since it is documentation and not code, is it OK to > > commit this now? > > The added text needs some copy-editing, I think. How about > > Since the output of this data type is locale-sensitive, it may not > work to load money data into a database that has a different > setting of lc_monetary. To avoid problems, before > restoring a dump make sure lc_monetary has the same value > as in the database that was dumped. > > (Actually, the first of the two lc_monetary references should be > an xref link to the GUC variable, but I'm too lazy to type that out.) > > A more direct approach to the problem might be to change pg_dump to > set lc_monetary, as it does for client_encoding ... Certainly OK by me. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] type money causes unrestorable dump
On Tue, 9 Oct 2007 13:16:08 -0400 "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote: > On Tue, 9 Oct 2007 19:02:38 +0200 > Peter Eisentraut <[EMAIL PROTECTED]> wrote: > > Am Dienstag, 9. Oktober 2007 schrieb D'Arcy J.M. Cain: > > > + Due to locale changes this type may have problems with dump and > > > + restore and care should be taken. > > > > With respect, this kind of advice is useless. What are the problems, when > > do > > they occur, and what should be done about them? We do know the answers to > > all of these questions. > > Right. How about this: > > ... > restore and care should be taken when dumping and reloading from > different locales. To avoid problems always explicitely set your > locale before both a dump and reload and make sure that they are > identical. I never received a response on this. Here is the full diff with the above change. Since it is documentation and not code, is it OK to commit this now? Index: datatype.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v retrieving revision 1.211 diff -u -p -u -r1.211 datatype.sgml --- datatype.sgml 21 Oct 2007 20:04:37 - 1.211 +++ datatype.sgml 3 Nov 2007 12:03:55 - @@ -834,14 +834,6 @@ ALTER SEQUENCE Monetary Types - - - The money type is deprecated. Use - numeric or decimal instead, in - combination with the to_char function. - - - The money type stores a currency amount with a fixed fractional precision; see Monetary Types -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Can a C function(server program) be a UDP or TCP server?
On Thu, 18 Oct 2007 11:24:24 -0400 "Billow Gao" <[EMAIL PROTECTED]> wrote: > I can write the network program. > But I am not 100% sure whether I can add the c-language function ( > http://www.postgresql.org/docs/8.2/interactive/xfunc-c.html) > to PostgreSQL. The function will be dynamic loaded by PostgreSQL. > I want to know whether there are any limitation on the function I wrote. > > for example: > If I want to write a function: > > PG_FUNCTION_INFO_V1(c_talktoremoteudp); > > > And use it in PostgreSQL like: > > = > SELECT name, c_talktoremoteudp > > (emp, 1500) AS overpaid > FROM emp > WHERE name = 'Bill' OR name = 'Sam'; > > = > The function c_talktoremoteudp will: > 1. send udp data to remote udp server > 2. monitor an udp port and wait for the reply > 3. return the data to the select query. I am confused. The dynamic function resides in the server. The query runs in the server. Where is the "remoteness" in any of this? Are you saying that there is a second server that is not PostgreSQL that uses UDP that you want to communicate with and merge info into the PostgreSQL server from? -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Can a C function(server program) be a UDP or TCP server?
On Thu, 18 Oct 2007 10:55:19 -0400 "Billow Gao" <[EMAIL PROTECTED]> wrote: > Is it possible to write a dynamic loaded C function as an UDP or TCP server? > > What we want to do it is: > Add a search function which send a UDP package to remote UDP server > and then listen to an UDP port, waiting for the result. > Ideally, we don't close the UDP server after the search query end. > So we can reuse it for next search. > > Is it possible? Short answer: yes. Slightly longer answer: If you need to ask this quetion then you should really talk to someone about network programming but this is the wrong list. If you are asking if PostgreSQL already does UDP then the answer is no. You need to write a server program that talks UDP in one direction and TCP to PostgreSQL in the other direction. Watch out for security issues. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Release notes introductory text
On Thu, 11 Oct 2007 16:34:14 -0400 (EDT) Bruce Momjian <[EMAIL PROTECTED]> wrote: > Kevin Grittner wrote: > > > PostgreSQL. Many complex ideas that normally take years > > > to implement were added rapidly to this release by our development team. > > > > You do realize that this will make many managers very reluctant to adopt > > it before it has settled in for many months, right? > > > > If the goal is to provide fair warning of a high-than-usual-risk > > release, you've got it covered. > > No, that was not the intent. The indent was to say we got a lot done in > one year. You have a suggestion? What if you changed "were added rapidly" to "were quickly brought to maturity" or something like that? -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] type money causes unrestorable dump
On Tue, 9 Oct 2007 19:02:38 +0200 Peter Eisentraut <[EMAIL PROTECTED]> wrote: > Am Dienstag, 9. Oktober 2007 schrieb D'Arcy J.M. Cain: > > + Due to locale changes this type may have problems with dump and > > + restore and care should be taken. > > With respect, this kind of advice is useless. What are the problems, when do > they occur, and what should be done about them? We do know the answers to > all of these questions. Right. How about this: ... restore and care should be taken when dumping and reloading from different locales. To avoid problems always explicitely set your locale before both a dump and reload and make sure that they are identical. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] type money causes unrestorable dump
[Note: Cc list trimmed as everyone is probably on the list anyway] On Tue, 9 Oct 2007 09:02:09 -0700 "Joshua D. Drake" <[EMAIL PROTECTED]> wrote: > However, keep in mind that I really don't care if Money is deprecated > or not. I do care that the docs say it is, and it may not be. :) Understood. Personally I would like to see that comment dropped but it isn't my decision. I did fix the biggest complaints in the recent change to 64 bit storage so perhaps someone can see their way clear to dropping that comment. Here is a suggested change. Index: datatype.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v retrieving revision 1.209 diff -u -p -u -r1.209 datatype.sgml --- datatype.sgml 31 Aug 2007 04:52:29 - 1.209 +++ datatype.sgml 9 Oct 2007 16:30:13 - @@ -828,14 +828,6 @@ ALTER SEQUENCE Monetary Types - - - The money type is deprecated. Use - numeric or decimal instead, in - combination with the to_char function. - - - The money type stores a currency amount with a fixed fractional precision; see Monetary Types -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] type money causes unrestorable dump
On Mon, 8 Oct 2007 20:02:56 -0700 "Joshua D. Drake" <[EMAIL PROTECTED]> wrote: > The money data type has been deprecated for years. It is completely non > standard and essentially duplicative of numeric/decimal. What is the > point? It may be deprecated (maybe not) and it may have drawbacks but it is not a duplication of numeric or decimal. While numeric/decimal may be faster for I/O, money is faster for doing large sums. Depending on your needs it does have an advantage over numeric. That said, I wonder if there is another answer to this question. Perhaps the functions in cash.c can be pulled out and made into external functions that can be fed an int (long) and output the desired format. That way we could use the existing int or long type but convert manually on I/O. Let people choose whether they want the simplification of the money type or the standardization allowed by just using the functions. Just a thought. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] adding operators
On Mon, 1 Oct 2007 12:38:07 +1000 "Brendan Jurd" <[EMAIL PROTECTED]> wrote: > On 10/1/07, Islam Hegazy <[EMAIL PROTECTED]> wrote: > > I am a graduate student in the University of Calgary. I want to add some new > > operators to PostgreSQL to perform some specific tasks in a project I am > > working in. My problem is that I cannot find my way into the code, where > > should I start and where to find the documentation for the code. > > There's no need to hack Postgres to add operators. You can do so by > defining functions using CREATE FUNCTION, and then hooking operators > up to them using CREATE OPERATOR. And if you need to add C code you can do that too. Check some examples in contrib such as my chkpass module for examples. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] more problems with the money type
On Mon, 20 Aug 2007 20:00:47 -0400 Andrew Chernow <[EMAIL PROTECTED]> wrote: > >>> What does "SELECT 2 * '3'::money;" do? > That works. > > >>try changing "64" to "32" in the function cash_mul_int4 > That also worked. > > See submitted patch that fixes cash_send and cash_recv as well. > Patch: http://archives.postgresql.org/pgsql-patches/2007-08/msg00117.php I am still waiting for Magnus to restore my CVS access following the move. Can someone else commit these fixes? -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] more problems with the money type
On Mon, 20 Aug 2007 17:32:42 -0400 "Merlin Moncure" <[EMAIL PROTECTED]> wrote: > while playing with the binary transport of the money type we found > another bug. The following code segfaults the server on 8.3cvs: > > select '3'::money * 2; What does "SELECT 2 * '3'::money;" do? If that works try changing "64" to "32" in the function cash_mul_int4. Let me know and I will commit the fix as soon as I get CVS access again. > aside: since the money type was deprecated, why was it bumped to 64 bits? See the archives. -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(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: [HACKERS] Blowback from text conversion changes
On Mon, 25 Jun 2007 17:56:28 +0100 Gregory Stark <[EMAIL PROTECTED]> wrote: > > This seems odd. It's not deciding that it's ambiguous or coming from another > datatype for which no implicit cast exists. It knows perfectly well that it > wants to convert to text but fails? > > > postgres=# select 'a'||b from (select 'b' as b) as x; > ERROR: failed to find conversion function from unknown to text It isn't the destination type that is the problem here but the source. I suppose that it could default 'b' to text but really, that isn't necessarily what '' signifies. How about '2007-06-25'? Is that text, date or timestamp? Try this. select 'a'||b from (select 'b'::text as b) as x; -- D'Arcy J.M. Cain <[EMAIL PROTECTED]> | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Money type todos?
On Wed, 21 Mar 2007 02:13:54 -0700 August Zajonc <[EMAIL PROTECTED]> wrote: > Agreed with Tom on this one. Full usage of money is beyond tagged types > etc. For example, when you earn money in another currency, it is the > time at which you earn it that describes its value. So for P&L accounts > there is generally no change in exchange rates over time and you need to > track what the rate was at time of earning. Solution is to date earnings > and have a table of exchange rates by day. Or hour or minute or second depending on the business rules. This is one of the reasons that I don't see currency information being embedded too deeply into the type beyond simple tagging. I find that when I need to work with exchange rates that I am better off just storing the original amount in one field for display purposes and the exchanged amount based on the exact time of the transaction in another. Even tagging the type gives me pause. I would want to do some testing to see if checking the tag slows down calculations. All of the suggested functionality of tagged types can be done with extra fields and rules anyway so you can get whatever your business rules dictate without it. > For balance sheet accounts, their value at a given point in time in a > home currency is of course dependent on exchange rates which creates the > currency gain or loss on the P&L side, the account that captures > exchange rate movements. But this is dependent on the relative > differences between the rates when every dollar was earned and current > rates. Exactly the sort of complication that I don't think belongs in the core database. These sorts of things need to be in contrib. > Darcy had suggested removing the currency symbol. That is a change I'd In fact, that was in my original patch when the type was widened. I only took it out of the proposal because it muddied the waters and made for too many (i.e. > 1) big changes in one patch. I am still willing to remove it now as a separate patch if that is the concensus. > support. The only other nice thing would be user defined precision, but > can live without that as most currencies work under nnn.mm. Speed is This is probably the single biggest thing keeping the type from being more widely accepted since it enforces a specific business rule on the type albeit a very ubiquitous one. > everything in these systems. For a complex general system you often can > get away with integers if you define at the app layer the handling > (including a lookup in system for format, type). Sometimes a "psql -c" is all you need to get useful information. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Money type todos?
On Wed, 21 Mar 2007 02:31:44 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > Dennis Bjorklund <[EMAIL PROTECTED]> writes: > > Tom Lane skrev: > >> Whether it is actually ever going to disappear is not agreed upon. > > > What is the reason to keep it? > > The words-of-one-syllable answer is that D'Arcy Cain is still willing > to put work into supporting the money type, and if it still gets the > job done for him then it probably gets the job done for some other > people too. My testing suggests that the money type is faster for certain tasks involving internal calculations usually and slower on others such as I/O. In fact I would like to find out what NUMERIC does to get its speed and see if MONEY can use that. > So I'm not feeling inclined to try to prescribe that datatype X is > good while datatype Y is bad. It's more about whether there's an > audience for any particular datatype definition. The present money > code gets the job done for D'Arcy and probably some other people, > and we see some straightforward ways to improve it to serve some > more cases, so what's wrong with pursuing that path? I still get the odd message from people telling me that they hope it stays in. I suspect that the main reason that more people don't use it is that we keep saying that it is going away. Perhaps we should either put forward an actual schedule for removing it or stop telling people that it is deprecated. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(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: [HACKERS] Money type todos?
On Tue, 20 Mar 2007 11:24:00 -0700 "Joshua D. Drake" <[EMAIL PROTECTED]> wrote: > The money type is considered deprecated. I was also under the impression > it would be eventually removed. Why are we accumulating TODOs for it? > > # -Make 64-bit version of the MONEY data type Actually, this TODO is DONE. It's in HEAD now. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Ooops ... seems we need a re-release pronto
On Sun, 11 Feb 2007 12:30:45 -0500 Tom Lane <[EMAIL PROTECTED]> wrote: > "D'Arcy J.M. Cain" writes: > > How about a rule that says no new ode without a test? > > We've got way too many tests like that already, ie, a bunch of > mostly-redundant functional tests of isolated new features. > Most of the code I worry about there isn't any simple way to > test from the SQL level --- the fact that a query gives the > right answer doesn't prove it went through a particular part > of the planner, for example. Well, that is covered in the system that I took that from. The full description is; 1. Identify a bug or missing feature. 2. Write the test that proves the bug or missing feature. 3. Run the test to prove that it fails. 4. Code until the test passes and then stop. 5. Run the regression test to make sure you didn't break something. Step 3. is the critical one from the point of view of your concern. Having a test that can't fail is worse than no test. This is taken from the principles of extreme programming. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Ooops ... seems we need a re-release pronto
On Sat, 10 Feb 2007 10:36:56 +0100 Peter Eisentraut <[EMAIL PROTECTED]> wrote: > Tom Lane wrote: > > I'm not concerned so much about the runtime as the development and > > maintenance effort... > > Shouldn't we at least add the one or two exemplary statements that > failed so we have some sort of coverage of the problem? How about a rule that says no new ode without a test? That's one of the ways that extreme programming is applied to new projects. Basically what that means is that bugs continue to be found but we never see the same bug twice because the regression test catches those. Of course, while you are creating one test you can always add a few related ones. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [COMMITTERS] pgsql: Widen the money type to 64 bits.
On Sun, 7 Jan 2007 21:04:09 -0800 (PST) Jeremy Drake <[EMAIL PROTECTED]> wrote: > This commit message is rather old, I remarked on its absence earlier, but > better late than never I guess ;) Not sure what you mean. I just committed it recently. I held off until after the release as requested. What do you mean by "old?" -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] New version of money type
On Thu, 21 Dec 2006 10:47:52 -0500 Tom Lane <[EMAIL PROTECTED]> wrote: > One bug I see in it is that you'd better make the alignment 'd' if the > type is to be int8. Also I much dislike these changes: > > - int32 i = PG_GETARG_INT32(1); > + int64 i = PG_GETARG_INT32(1); I changed this and a few other things. I didn't see any response to my question though. Shall I go ahead and commit now so that we can test in a wider setting? I haven't committed anything in years and I am hesitant to do so now without consencus. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Possible documentation error
On Tue, 26 Dec 2006 18:12:45 +0100 Martijn van Oosterhout wrote: > On Tue, Dec 26, 2006 at 12:04:40PM -0500, D'Arcy J.M. Cain wrote: > > Now it certainly seems to me that it should behave as described given > > the definition of VACUUM FULL so I am a little confused by my tests. > > My test table only has two entries in it. Is that the issue? In fact, > > I find the same behaviour if I do a simple VACUUM on the table. > > On a table with two entries, VACUUM FULL is going to do nothing of > interest. Moving tuples within a page is useless, generally. I thought that that might be the issue. The docs should probably say "can" instead of "will" then. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Possible documentation error
http://www.postgresql.org/docs/8.2/interactive/ddl-system-columns.html has the following statement about ctid: "The physical location of the row version within its table. Note that although the ctid can be used to locate the row version very quickly, a row's ctid will change each time it is updated or moved by VACUUM FULL. Therefore ctid is useless as a long-term row identifier. The OID, or even better a user-defined serial number, should be used to identify logical rows." I have been testing this statement and find that it seems not quite true. Although ctid changes on update, VACUUM FULL does not change it. What it does do is make lower areas available again so an update after a VACUUM FULL can reuse lower numbers rather than higher ones before. Now it certainly seems to me that it should behave as described given the definition of VACUUM FULL so I am a little confused by my tests. My test table only has two entries in it. Is that the issue? In fact, I find the same behaviour if I do a simple VACUUM on the table. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] New version of money type
On Thu, 21 Dec 2006 10:47:52 -0500 Tom Lane <[EMAIL PROTECTED]> wrote: > One bug I see in it is that you'd better make the alignment 'd' if the > type is to be int8. Also I much dislike these changes: > > - int32 i = PG_GETARG_INT32(1); > + int64 i = PG_GETARG_INT32(1); As I have made the few corrections that you pointed out, should I go ahead and commit so that it can be tested in a wider group? Also, there are further ideas out there to improve the type further that would be easier to handle with this out of the way. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] New version of money type
On Thu, 21 Dec 2006 10:47:52 -0500 Tom Lane <[EMAIL PROTECTED]> wrote: > "D'Arcy J.M. Cain" writes: > > Very good points. However, like the currency symbol issue I would like > > to separate that into another discussion. The code already exists with > > the warts you mention (and more) and this proposal is to fix one thing > > that will make it more useful to others. Let's get that change in and > > then start fixing up some of those other issues. > > I've forgotten now --- was this patch intended *only* to convert money > from int4 to int8 underlying representation, or did you do other things? Well, the main intention was to just widen the underlying storage and thus increase the range to the point that the type is useful to more users. In fact, as you can see, I have removed the change to drop the currency on output just to keep this change to a single issue. However, there was a little bit of cleanup as well. I removed some self-balancing XXX comments for example. That's what CVS log is for. I moved a few functions around in order to make static functions self prototyping. I added some consts to variables where appropriate. The cash_words function needed to be changed to accomodate the billions, trillions and quadrillions that can now be handled. Everything else should be directly related to the type change and self-explanatory. > It looks like there are unrelated changes in the patch, but I'm not sure > if you just moved code around or did something more interesting. Hopefully nothing too "interesting." :-) > One bug I see in it is that you'd better make the alignment 'd' if the Fixed in my local tree. Thanks. > type is to be int8. Also I much dislike these changes: > > - int32 i = PG_GETARG_INT32(1); > + int64 i = PG_GETARG_INT32(1); > > I think they may not actually be wrong, but they certainly *look* wrong; > in general the declared type of a parameter variable in a C-coded SQL > function ought to match what the SQL signature says. Anyway there is no > need that I can see to widen these variables. Every C compiler knows > what to do if you ask it for arithmetic on a long and an int. Right but I still need to accept int64 args here. I have changed the two relevant places to use PG_GETARG_INT64(1). > (Speaking of which, have you thought about what happens on a machine > with no 64-bit int, such that "int64" is really just 32 bits? Ideally > the code should continue to function but with reduced range. I didn't > see any places where you were obviously depending on the range, but > it's something to have in the back of your mind while coding.) Does PGSQL run on any such machines? If so perhaps someone can volunteer to do some testing if they have one. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] New version of money type
On Thu, 21 Dec 2006 00:21:08 -0800 David Fetter <[EMAIL PROTECTED]> wrote: > On Wed, Dec 20, 2006 at 08:44:07PM -0500, D'Arcy J.M. Cain wrote: > > Now that 8.3 has been branched shall I go ahead and commit? As > > discussed I will put the currency symbol back in just so that it can > > be discussed and worked on as a completely separate issue. I have > > attached the current patch against HEAD. > > I noticed that all your numbers are in English. Is it necessary to > hard-code all that? Also, you're assuming that powers of 10 which are > divisible by 3 are the relevant ones. In China, it's powers of 10 > divisible by 4, and in India, it's 0, 1, 2, 3, followed by odd numbers > up through 19. Very good points. However, like the currency symbol issue I would like to separate that into another discussion. The code already exists with the warts you mention (and more) and this proposal is to fix one thing that will make it more useful to others. Let's get that change in and then start fixing up some of those other issues. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] New version of money type
On Thu, 12 Oct 2006 14:24:22 -0400 "D'Arcy J.M. Cain" wrote: > On Thu, 12 Oct 2006 14:17:33 -0400 > Tom Lane <[EMAIL PROTECTED]> wrote: > > "D'Arcy J.M. Cain" writes: > > > Cool. So what do I do with the patch? Should I add the currency > > > symbol back in and commit or should I resubmit the patch to hackers for > > > further review? > > > > Well, one thing you definitely *don't* do is commit right now, because > > we're in feature freeze, not to mention trying to avoid forced initdbs > > now that beta has started. Sit on it till 8.3 is branched, and > > OK. I hadn't thought of it as a new feature per se but I understand > the initdb issue. Holding at 30,000 feet, ground control. > > > meanwhile think about what you want to do with the currency-symbol > > issue... > > Personally I don't see a need for it but I am currently in favour of > adding it back in before committing just so that we can deal with the > issue separately. The same as the other changes being discussed. Now that 8.3 has been branched shall I go ahead and commit? As discussed I will put the currency symbol back in just so that it can be discussed and worked on as a completely separate issue. I have attached the current patch against HEAD. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. cash64_patch Description: Binary data ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Syntax bug? Group by?
On Tue, 17 Oct 2006 12:08:07 -0400 Stephen Frost <[EMAIL PROTECTED]> wrote: > * Mark Woodward ([EMAIL PROTECTED]) wrote: > > If I am asking for a specific column value, should I, technically > > speaking, need to group by that column? > > Technically speaking, if you're asking for a specific tuple, should you > be allowed to request an aggregation? One column value doesn't necessarily mean one tuple unless it has a unique index on that column. SELECT COUNT(*) FROM table WHERE field = 'value'; That's perfectly reasonable. You don't need the GROUP BY clause. However, this doesn't sound like a hackers question. Next time, please ask on another list such as pgsql-sql or even pgsql-novice. You can review the mailing lists and their purpose at http://www.postgresql.org/community/lists/ -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] New version of money type
On Thu, 12 Oct 2006 14:17:33 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > "D'Arcy J.M. Cain" writes: > > Cool. So what do I do with the patch? Should I add the currency > > symbol back in and commit or should I resubmit the patch to hackers for > > further review? > > Well, one thing you definitely *don't* do is commit right now, because > we're in feature freeze, not to mention trying to avoid forced initdbs > now that beta has started. Sit on it till 8.3 is branched, and OK. I hadn't thought of it as a new feature per se but I understand the initdb issue. Holding at 30,000 feet, ground control. > meanwhile think about what you want to do with the currency-symbol > issue... Personally I don't see a need for it but I am currently in favour of adding it back in before committing just so that we can deal with the issue separately. The same as the other changes being discussed. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] New version of money type
On Thu, 12 Oct 2006 13:21:37 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > > Well, the patch I submitted is definitely an improvement over the > > existing version. Are you saying that I have to make further > > improvements before these ones can be imported? > > I didn't say that. I was responding to someone whose position seemed to > be "money is going to be removed, therefore you shouldn't work on it". > I wanted to know exactly what would need to be fixed before they'd not > want it removed. Cool. So what do I do with the patch? Should I add the currency symbol back in and commit or should I resubmit the patch to hackers for further review? -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New version of money type
On Thu, 28 Sep 2006 23:23:30 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > > The existing type is depricated and has been since at least 8.1; so yes, > > it's slated for removal. > > Well, my perception of that has always been "it needs to be upgraded or > removed". So if D'Arcy wants to work on the improvement angle, I have > no problem with him doing so. The thing we need to negotiate is "how > much improvement is needed to keep it in core". Well, the patch I submitted is definitely an improvement over the existing version. Are you saying that I have to make further improvements before these ones can be imported? ISTM that going to 64 bit without any other change is big enough to warrant the change as is. Once that is done I would be happy to work on other improvements but my experience tells me not to make more than one major change at a time. The one issue I have with my existing patch though is the removal of the currency symbol from the output. There have been many suggestions that that just gets in the way but, following up on my own statement above, this is two changes, not one, and perhaps should be left out of the patch for that reason. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] New version of money type
On Thu, 28 Sep 2006 22:53:34 +0200 Martijn van Oosterhout wrote: > Every new type needs to have a well-defined use-case before it can be > considered for includion. Well, it is already included. The current proposal is simply to improve the existing type. I guess you are arguing a different proposal altogether - to remove the existing type. > Currently we have: > - Is possibly faster than numeric I suppose I should quantify this but it's hard to get motivated after the many man-hours (mine and my staff) I had to spend on code and schema optimizations I needed to do just to get closer to the previous speed our aps had before we converted from money to numeric. I will try to find time to put together a test that appoximates that real world example. > - Takes less space than numeric Never really considered this a major improvement over numeric given the cost of disk these days. I suppose it could be contributing to the speed increase. > - Customisable output (only one currency at a time though) > - Fixed number of decimal places The original code actually handled number of decimal places. It tended to cause problems though. These are areas that the existing type, as well as the proposed change, could be worked on. I would hesitate to work on both together though and going to 64bit will probably add more value right now than those things, certainly for existing users of the type. By the way, the current proposal actually removes the currency symbol but I have received complaints about that. It should probably go back just because it is outside of the scope of the primary change. That can be dealt with later. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
