Re: [HACKERS] PQnotifies() in 7.3 broken?
Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Greg Copeland wrote: Is it possible to automate this as part of the build process so that they get grabbed from some version information during the build? Version bump is one of the few things we do at the start of development. The real problem here is that major version bump (signifying an incompatible API change) is something that must NOT be done in an automated, mindless-checklist way. We should have executed the bump when we agreed to change PQnotifies' API incompatibly. We screwed up on that. I think it's correct to fix the error for 7.3.1 --- but we cannot improve on the situation by making some procedural change to always do X at point Y in the release cycle. Sometimes there's no substitute for actual thinking :-( Oh, a major bump. I thought we did major bumps only in cases where a recompile will _not_ fix the problem, like changing a parameter value to a function or removing a function or something like that. That's not strictly how the major and minor numbers were intended to be used, at least as I understand it. The reason you really have no choice but to bump the major number in the case of the introduction of binary incompatibilities (whether or not a recompile would fix it) is that the dynamic linker usually uses the major version *only* to determine which library to dynamically link against (but see below for a caveat). So what's the purpose of the minor version number? To indicate which revision of the library is in use. It may be that version 2.1 has bugfixes that 2.0 doesn't have, so the minor version number allows you to determine whether or not you have the fixes in question. Generally, you can specify at library build time whether an application must link with a specific major/minor numbered library, or whether it can link against any library with the same major number. Most people do the latter, and that's as it should be. If the PostgreSQL libraries (for instance) required a match against the minor number, then applications would have to be recompiled every time PostgreSQL was upgraded. Not only is that highly undesirable, for some it may not even be possible (e.g., when using commercial applications). -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Croatian language file for 7.3
On Tuesday 10 December 2002 20:05, Peter Eisentraut wrote: Done. Great. I have translation for psql half-done. I'll send it as soon as finished. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] DB Tuning Notes - Where To?
Just wondering where I should put my modified tuning notes. I was planning on making them section 3.7 in the Admin guide. Does that sound reasonable? The current version can be seen at: http://www.rhyme.com.au/manuals/pgsql-7.3/postmaster-tuning-software.html I think it's important we get something on tuning into the manual - I'm not particularly attached to where. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Problems with ALTER DOMAIN patch
On Wed, 2002-12-11 at 00:05, Tom Lane wrote: Rod Taylor [EMAIL PROTECTED] writes: On Tue, 2002-12-10 at 22:56, Tom Lane wrote: relation's pg_class row. We have no such locks on types at present, but I think it may be time to invent 'em. I'd be happy to use them once created. I think you misunderstood me ;=) ... that was a none-too-subtle Nope... I understood. But it could take quite a while. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] DB Tuning Notes - Where To?
On Wed, 2002-12-11 at 09:40, Philip Warner wrote: Just wondering where I should put my modified tuning notes. I was planning on making them section 3.7 in the Admin guide. Does that sound reasonable? The current version can be seen at: http://www.rhyme.com.au/manuals/pgsql-7.3/postmaster-tuning-software.html I think it's important we get something on tuning into the manual - I'm not particularly attached to where. I had thought the information would be tied to the relevant sections of 3.4 Run-time Configuration. I'm not sure where the vacuum/analyze information would go in this scenario though, so a general software tuning section does seem appropriate. Do you see a 3.8 Tuning the Server (Hardware) section as well? Robert Treat ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] DB Tuning Notes - Where To?
At 10:25 AM 11/12/2002 -0500, Robert Treat wrote: Do you see a 3.8 Tuning the Server (Hardware) section as well? Hardware and/or OS. I think Bruce's tuning docs tend to address the hardware and environmental issues, so I was not planning to write anything myself. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] http://www.postgresql.org/idocs/ is down
http://www.postgresql.org/idocs/ is down Warning: Unable to connect to PostgreSQL server: The Data Base System is shutting down in /usr/local/www/www/idocs/opendb.php on line 3 Unable to access database -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] http://www.postgresql.org/idocs/ is down
Hi Dan, Thanks for pointing this out. The Admin guys are looking into it now. Hopefully it'll be fixed soon. :-/ Regards and best wishes, Justin Clift Dan Langille wrote: http://www.postgresql.org/idocs/ is down Warning: Unable to connect to PostgreSQL server: The Data Base System is shutting down in /usr/local/www/www/idocs/opendb.php on line 3 Unable to access database -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] http://www.postgresql.org/idocs/ is down
Hi Dan, The database for the postgresql.org sites is back up again now. Thanks for pointing it out. :-) Regards and best wishes, Justin Clift Justin Clift wrote: Hi Dan, Thanks for pointing this out. The Admin guys are looking into it now. Hopefully it'll be fixed soon. :-/ Regards and best wishes, Justin Clift Dan Langille wrote: http://www.postgresql.org/idocs/ is down Warning: Unable to connect to PostgreSQL server: The Data Base System is shutting down in /usr/local/www/www/idocs/opendb.php on line 3 Unable to access database -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PQnotifies() in 7.3 broken?
Bruce Momjian writes: OK, seeing that we don't have a third number, do people want me to increment the interface numbers for 7.3.1, or just wait for the increment in 7.4? ISTM that the briefly established strategy to bump the version numbers at the beginning of development is not satisfactory. The reason is that the beginning is in many cases not well-defined. Example 1: If we hadn't noticed the PQnotifies() problem that started this thread we would have forgotten again. Example 2: If someone put a fix of some sort in libpq for 7.3.1, we would surely forget to bump the version number. Consequence: The library version number must be bumped as part of the release preparation, as is in fact written down in the release checklist. And such a bump should be done only after reviewing the change history of the library during that development cycle to determine if a major bump is necessary or if in fact no change at all is warranted. As for what to do right now, if others agree I would suggest that we do the appropriate version number adjustments (as described in the previous paragraph) for 7.3.1. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] proposal: array utility functions phase 1
Tom Lane wrote:
It seems like somehow we need a level of FROM/WHERE producing some base
rows, and then a set of table function calls to apply to each of the
base rows, and then another level of WHERE to filter the results of the
function calls (in particular to provide join conditions to identify
which rows to match up in the function outputs). I don't see any way to
do this without inventing new SELECT clauses out of whole cloth
... unless SQL99's WITH clause helps, but I don't think it does ...
Well, maybe this is a start. It allows a table function's input parameter to
be declared with setof. The changes involved primarily:
1) a big loop in ExecMakeTableFunctionResult so that functions with set
returning arguments get called for each row of the argument,
and
2) aways initializing the tuplestore in ExecMakeTableFunctionResult and
passing that to the function, even when SFRM_Materialize mode is used.
The result looks like:
create table foot(f1 text, f2 text);
insert into foot values('a','b');
insert into foot values('c','d');
insert into foot values('e','f');
create or replace function test2() returns setof foot as 'select * from foot
order by 1 asc' language 'sql';
create or replace function test(setof foot) returns foot as 'select $1.f1,
$1.f2' language 'sql';
regression=# select * from test(test2());
f1 | f2
+
a | b
c | d
e | f
(3 rows)
I know it doesn't solve all the issues discussed, but is it a step forward?
Suggestions?
Joe
Index: contrib/tablefunc/tablefunc.c
===
RCS file: /opt/src/cvs/pgsql-server/contrib/tablefunc/tablefunc.c,v
retrieving revision 1.11
diff -c -r1.11 tablefunc.c
*** contrib/tablefunc/tablefunc.c 23 Nov 2002 01:54:09 - 1.11
--- contrib/tablefunc/tablefunc.c 11 Dec 2002 22:07:01 -
***
*** 53,59
int max_depth,
bool show_branch,
MemoryContext per_query_ctx,
! AttInMetadata *attinmeta);
static Tuplestorestate *build_tuplestore_recursively(char *key_fld,
char *parent_key_fld,
char *relname,
--- 53,60
int max_depth,
bool show_branch,
MemoryContext per_query_ctx,
! AttInMetadata *attinmeta,
! Tuplestorestate *tupstore);
static Tuplestorestate *build_tuplestore_recursively(char *key_fld,
char *parent_key_fld,
char *relname,
***
*** 641,646
--- 642,648
char *branch_delim = NULL;
boolshow_branch = false;
ReturnSetInfo *rsinfo = (ReturnSetInfo *) fcinfo-resultinfo;
+ Tuplestorestate *tupstore;
TupleDesc tupdesc;
AttInMetadata *attinmeta;
MemoryContext per_query_ctx;
***
*** 673,678
--- 675,681
allowed in this context);
/* OK, go to work */
+ tupstore = rsinfo-setResult;
rsinfo-returnMode = SFRM_Materialize;
rsinfo-setResult = connectby(relname,
key_fld,
***
*** 682,688
max_depth,
show_branch,
per_query_ctx,
! attinmeta);
rsinfo-setDesc = tupdesc;
MemoryContextSwitchTo(oldcontext);
--- 685,692
max_depth,
show_branch,
per_query_ctx,
! attinmeta,
! tupstore);
rsinfo-setDesc = tupdesc;
MemoryContextSwitchTo(oldcontext);
***
*** 709,732
int max_depth,
bool show_branch,
MemoryContext per_query_ctx,
! AttInMetadata *attinmeta)
{
- Tuplestorestate *tupstore = NULL;
int ret;
- MemoryContext oldcontext;
/* Connect to SPI manager */
if ((ret = SPI_connect()) 0)
elog(ERROR, connectby: SPI_connect returned %d, ret);
- /* switch to longer term context to create the tuple store */
- oldcontext = MemoryContextSwitchTo(per_query_ctx);
-
- /* initialize our tuplestore */
- tupstore = tuplestore_begin_heap(true,
[HACKERS] SCO Openserver supported in 7.3.1
I have worked with Shibashish Satpathy to add support for SCO Openserver 5.0.4 using gcc in 7.3.1. The port was accomplished via a small change to template/sco. Seeing as it was an unsupported platform, this is a no-risk change, because now it _does_ work. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PQnotifies() in 7.3 broken?
Bruce Momjian wrote: We bump at the beginning only because we _know_ we want new users to use the newer library. (Does the runtime linker know to get the highest minor numbered library with the same major number?) It probably depends on the system, but the runtime linker isn't that smart under Linux. It looks for a match for the major version only, so for instance in the case of libpq major version 2, it'll look for libpq.so.2 in the library search path. Multiple minor versions of the library are managed via symlinks under Linux (libpq.so.2 - libpq.so.2.2, for instance). Bumping at the end is done only when we know there is some change. The big question is whether a change in the API or a change in the code (recompile) is enough to bump that major version number. We always make some force-recompile change in the library in each release, don't we? Do we just bump the major in every major release? It wouldn't be a terribly bad idea to do that, but the main criteria for bumping the major version should be binary compatibility. If applications which link against libpq.so.2 reside on the system and libpq.so.2.3 has binary incompatibilities with libpq.so.2.2, then installing libpq.so.2.3 on the system will break all the binaries that use libpq.so.2. That's why it's important to bump the major version when there are binary incompatibilities: you can install libpq.so.3 and all the while, applications that rely on libpq.so.2 will still run (because you can have both of those library versions installed on the system at the same time without conflict). I usually bumped the minor at the beginning because this allows beta testers to not have _extra_ versions of the library laying around, and also because we make minor library changes often during beta, so it isn't clear when to bump that number. I think it makes sense to change the minor number whenever there are code changes to the library that don't introduce binary incompatibilities. Whether you bump the minor version during a new release when there are no changes to the library itself is probably a matter of preference only. It doesn't really hurt anything and may make management of the version number easier. -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] SCO Openserver supported in 7.3.1
Bruce Momjian wrote: I have worked with Shibashish Satpathy to add support for SCO Openserver 5.0.4 using gcc in 7.3.1. The port was accomplished via a small change to template/sco. Seeing as it was an unsupported platform, this is a no-risk change, because now it _does_ work. Let me add something. I worked with Shibashish via Yahoo chat, and it was a very efficient way to do it. I am not sure if we could have done it via email. Chat is good for most interative processes. I now have access to +10 regular hackers posters, and this makes things easier when we want to knock ideas around in a more interactive way. My chat addresses are: AIM bmomjian ICQ 151255111 Yahoo bmomjian MSN [EMAIL PROTECTED] IRC bmomjian at #postgresql via EFNet or OpenProjects -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PQnotifies() in 7.3 broken?
Peter Eisentraut wrote: Bruce Momjian writes: OK, seeing that we don't have a third number, do people want me to increment the interface numbers for 7.3.1, or just wait for the increment in 7.4? ISTM that the briefly established strategy to bump the version numbers at the beginning of development is not satisfactory. The reason is that the We bump at the beginning only because we _know_ we want new users to use the newer library. (Does the runtime linker know to get the highest minor numbered library with the same major number?) Bumping at the end is done only when we know there is some change. The big question is whether a change in the API or a change in the code (recompile) is enough to bump that major version number. We always make some force-recompile change in the library in each release, don't we? Do we just bump the major in every major release? beginning is in many cases not well-defined. Example 1: If we hadn't noticed the PQnotifies() problem that started this thread we would have forgotten again. Example 2: If someone put a fix of some sort in libpq for 7.3.1, we would surely forget to bump the version number. Consequence: The library version number must be bumped as part of the release preparation, as is in fact written down in the release checklist. I usually bumped the minor at the beginning because this allows beta testers to not have _extra_ versions of the library laying around, and also because we make minor library changes often during beta, so it isn't clear when to bump that number. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Problems with ALTER DOMAIN patch
Rod Taylor wrote: -- Start of PGP signed section. On Wed, 2002-12-11 at 00:05, Tom Lane wrote: Rod Taylor [EMAIL PROTECTED] writes: On Tue, 2002-12-10 at 22:56, Tom Lane wrote: relation's pg_class row. We have no such locks on types at present, but I think it may be time to invent 'em. I'd be happy to use them once created. I think you misunderstood me ;=) ... that was a none-too-subtle Nope... I understood. But it could take quite a while. I have an idea. Rather than doing some complex locking for types, why don't we just restrict ALTER DOMAIN to cases where we are the only one attached to the database, as seen in dropdb(). Seems like an easy way to get the feature in without adding a new locking method. Also, it would allow the regression test to work too because no one is attached to 'regression' at the time of the test. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] DB Tuning Notes - Where To?
Philip Warner wrote: At 10:25 AM 11/12/2002 -0500, Robert Treat wrote: Do you see a 3.8 Tuning the Server (Hardware) section as well? Hardware and/or OS. I think Bruce's tuning docs tend to address the hardware and environmental issues, so I was not planning to write anything myself. I was unsure how _definiative_ the discussion was. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] DB Tuning Notes - Where To?
At 12:10 PM 12/12/2002 +1100, Philip Warner wrote: good starting point for tuning I think this probably sums it up. IMO it is grandiose to call it a tuning document; at best it is a 'Misbehaviour Avoidance' document. We probably need something about the usual database-side tuning options: indexes, WAL, page sizes etc, and something else about environmental options (moving files, RAID etc). Should I change the section name to 'Routine Maintenance'? Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] DB Tuning Notes - Where To?
Philip Warner wrote: At 12:10 PM 12/12/2002 +1100, Philip Warner wrote: good starting point for tuning I think this probably sums it up. IMO it is grandiose to call it a tuning document; at best it is a 'Misbehaviour Avoidance' document. We probably need something about the usual database-side tuning options: indexes, WAL, page sizes etc, and something else about environmental options (moving files, RAID etc). Yep, that sounds like it. We should have that right in the docs next to that tuning parameter, or somewhere in a separate section on freespace map and point there. Also, this may improve over releases so we need to track the changes in the official release. If we can convey how the free space map works, people will be able to understand how their workload affects it. Should I change the section name to 'Routine Maintenance'? Well, it isn't something you would play with regularly, like backups. It is more like the disk space analysis section I added in 7.3. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] DB Tuning Notes - Where To?
At 08:43 PM 11/12/2002 -0500, Bruce Momjian wrote: Well, it isn't something you would play with regularly, like backups. How about I call it 'Managing Server Resources' and put it between 'Runtime Configuration' and 'Managing Kernel Resources'? ie. it becomes 3.5. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PQnotifies() in 7.3 broken?
Kevin Brown wrote: It wouldn't be a terribly bad idea to do that, but the main criteria for bumping the major version should be binary compatibility. If applications which link against libpq.so.2 reside on the system and libpq.so.2.3 has binary incompatibilities with libpq.so.2.2, then installing libpq.so.2.3 on the system will break all the binaries that use libpq.so.2. That's why it's important to bump the major version when there are binary incompatibilities: you can install libpq.so.3 and all the while, applications that rely on libpq.so.2 will still run (because you can have both of those library versions installed on the system at the same time without conflict). I usually bumped the minor at the beginning because this allows beta testers to not have _extra_ versions of the library laying around, and also because we make minor library changes often during beta, so it isn't clear when to bump that number. I think it makes sense to change the minor number whenever there are code changes to the library that don't introduce binary incompatibilities. Whether you bump the minor version during a new release when there are no changes to the library itself is probably a matter of preference only. It doesn't really hurt anything and may make management of the version number easier. If it is true that the linker only matches the major number, what value is there in incrementing the minor number, as we have done in the past? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] DB Tuning Notes - Where To?
At 01:22 AM 12/12/2002 -0500, Tom Lane wrote: in my mind tuning activities will hold good till your database usage changes. What about my later suggestion of 'Managing Server Resources', going before 'Managing Kernel Resources'. Or perhaps, 'Tuning Server Resources'... The document describes how to set the config items and vacuum/analyze frequencies...so it should not be regularly performed. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [INTERFACES] Patch for DBD::Pg pg_relcheck problem
Perhaps compression should be added to the list of protocol changes. This way, we can allow for per packet evaluation for compression. -- Greg Copeland [EMAIL PROTECTED] Copeland Computer Consulting On Tue, 2002-12-10 at 21:50, Bruce Momjian wrote: Tom Lane wrote: Ian Barwick [EMAIL PROTECTED] writes: Sounds good to me. Is it on the todo-list? (Couldn't see it there). Probably not; Bruce for some reason has resisted listing protocol change desires as an identifiable TODO category. There are a couple of threads in the pghackers archives over the last year or so that discuss the different things we want to do, though. (Improving the error-reporting framework and fixing the COPY protocol are a couple of biggies I can recall offhand.) Listing protocol changes seemed too low-level for the TODO list, but I have kept the email messages. Today I updated the TODO list and added a section for them. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [INTERFACES] Patch for DBD::Pg pg_relcheck problem
Added to TODO. --- Greg Copeland wrote: Perhaps compression should be added to the list of protocol changes. This way, we can allow for per packet evaluation for compression. -- Greg Copeland [EMAIL PROTECTED] Copeland Computer Consulting On Tue, 2002-12-10 at 21:50, Bruce Momjian wrote: Tom Lane wrote: Ian Barwick [EMAIL PROTECTED] writes: Sounds good to me. Is it on the todo-list? (Couldn't see it there). Probably not; Bruce for some reason has resisted listing protocol change desires as an identifiable TODO category. There are a couple of threads in the pghackers archives over the last year or so that discuss the different things we want to do, though. (Improving the error-reporting framework and fixing the COPY protocol are a couple of biggies I can recall offhand.) Listing protocol changes seemed too low-level for the TODO list, but I have kept the email messages. Today I updated the TODO list and added a section for them. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
