Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
> I just committed changes that make it RESULT_OID, but if you like
> INSERTED_OID better, we could change it...
>>
>> I think I like RESULT_OID because the standard uses RESULT.
> RESULT* is used for SELECT statements, but RES
Bruce Momjian writes:
> > I just committed changes that make it RESULT_OID, but if you like
> > INSERTED_OID better, we could change it...
>
> I think I like RESULT_OID because the standard uses RESULT.
RESULT* is used for SELECT statements, but RESULT_OID is for INSERT
commands. It sounds a bi
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > I like this one - except for the OID which should IMHO read
> > INSERTED_OID.
>
> I just committed changes that make it RESULT_OID, but if you like
> INSERTED_OID better, we could change it...
Oh boy,
at your current sp
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > I like this one - except for the OID which should IMHO read
> > INSERTED_OID.
>
> I just committed changes that make it RESULT_OID, but if you like
> INSERTED_OID better, we could change it...
I think I like RESULT_OID because the standard us
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Open list updated. Looks like the list is done. Can I move "Stuck
> > btree spinlocks" to the TODO list. Is "visibility of joined columns in JOIN
> > clauses" done?
>
> I think both of those are actually done. Vadim might want to tweak
> the tim
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Open list updated. Looks like the list is done. Can I move "Stuck
> > btree spinlocks" to the TODO list. Is "visibility of joined columns in JOIN
> > clauses" done?
>
> I think both of those are actually done. Vadim might want to tweak
> the tim
Philip Warner wrote:
>
> Unfortunately, I don't have an awful lot of free time at the moment, so I
> won't be able to look at this for at *least* as week.
I'll do it as soon as we decided about the final syntax and
keywords.
Jan
--
#==
Jan Wieck <[EMAIL PROTECTED]> writes:
> I like this one - except for the OID which should IMHO read
> INSERTED_OID.
I just committed changes that make it RESULT_OID, but if you like
INSERTED_OID better, we could change it...
regards, tom lane
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Open list updated. Looks like the list is done. Can I move "Stuck
> btree spinlocks" to the TODO list. Is "visibility of joined columns in JOIN
> clauses" done?
I think both of those are actually done. Vadim might want to tweak
the timeouts I select
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Quoting a recent message by Jan Wieck <[EMAIL PROTECTED]>:
> > :Do a
> > :
> > :GET DIAGNOSTICS SELECT PROCESSED INTO ;
> > :
> > :directly after an INSERT, UPDATE or DELETE statement and you'll know
> > :how many rows hav
Tom Lane wrote:
> Philip Warner <[EMAIL PROTECTED]> writes:
> >> Hmm, that's definitely what SQL99 uses for the syntax. I wonder where
> >> Jan got the SELECT INTO syntax --- did he borrow it from Oracle?
>
> > Sadly, we made it up.
>
> Ah so. Well, friendliness aside, I'd go with the spec's syn
Philip Warner wrote:
>
> P.S. Is Jan around? He's been very quiet recently...
He is,
just a little quiet. I can live with it either way. The main
problem, as said, is that we need to allow some keywords as
identifiers in PL/pgSQL like in the main parser. Actually we
added RES
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Well, this clearly is a release-stopper because we don't want to release
> > a non-standard GET DIAGNOSTICS. It will be fixed before 7.1 final by
> > someone. I have added it to the open items list.
>
> Done.
>
> I ended up using RESULT_OID for t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Well, this clearly is a release-stopper because we don't want to release
> a non-standard GET DIAGNOSTICS. It will be fixed before 7.1 final by
> someone. I have added it to the open items list.
Done.
I ended up using RESULT_OID for the keyword that
Philip Warner <[EMAIL PROTECTED]> writes:
> Unfortunately, I don't have an awful lot of free time at the moment, so I
> won't be able to look at this for at *least* as week.
It looks like a pretty straightforward change; I'll try to get it done
today.
regards, tom lane
> We *do* need to support ROW_COUNT, but allowing
>
> GET DIAGNOSTICS Select ROW_COUNT, SQLCODE, OID Into :a,:b:,:c;
>
> is a lot friendlier than the standard:
>
> GET DIAGNOSTICS :a = ROW_COUNT;
> GET DIAGNOSTICS EXCEPTION 1 :b = SQLCODE;
> GET DIAGNOSTICS :c = OID;
>
> (not
> >> GET DIAGNOSTICS :c = OID;
> >
> >It looks to me like SQL99 allows
> >
> > GET DIAGNOSTICS :a = ROW_COUNT, :b = OID, ...;
>
> Yes, but condition information (eg. SPI RESULT or SQLCODE), needs a
> separate statement to row information (eg. ROW_COUNT). ie.
>
> GET DIAGNOSTICS :a =
At 20:40 18/02/01 -0500, Tom Lane wrote:
>Philip Warner <[EMAIL PROTECTED]> writes:
>>> Hmm, that's definitely what SQL99 uses for the syntax. I wonder where
>>> Jan got the SELECT INTO syntax --- did he borrow it from Oracle?
>
>> Sadly, we made it up.
>
>Ah so. Well, friendliness aside, I'd go
Philip Warner <[EMAIL PROTECTED]> writes:
>> Hmm, that's definitely what SQL99 uses for the syntax. I wonder where
>> Jan got the SELECT INTO syntax --- did he borrow it from Oracle?
> Sadly, we made it up.
Ah so. Well, friendliness aside, I'd go with the spec's syntax.
> We *do* need to supp
At 18:49 18/02/01 -0500, Tom Lane wrote:
>Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> :
>> :GET DIAGNOSTICS SELECT RESULT INTO ;
>
>> May I suggest that this is the wrong syntax? It should be
>
>Hmm, that's definitely what SQL99 uses for the syntax. I wonder where
>Jan got the SELECT INT
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Quoting a recent message by Jan Wieck <[EMAIL PROTECTED]>:
> :Do a
> :
> :GET DIAGNOSTICS SELECT PROCESSED INTO ;
> :
> :directly after an INSERT, UPDATE or DELETE statement and you'll know
> :how many rows have been hit.
> :
> :Also you can
At 12:15 16/02/01 -0500, Bruce Momjian wrote:
>
>Can someone comment on this? Seems GET DIAGNOSTICS is wrong from
>Peter's reading of SQL92, and mine too.
>
He's quite correct.
Philip Warner| __---_
Al
Hi there...
I would like to inquire of possible support for running PostgreSQL on a
Linux Cluster. How would i implement and configure PostgreSQL as a
distributed database i.e. replicated on several servers?
I am anxious to hear from you guys.
--
Manny C. Ca
Can someone comment on this? Seems GET DIAGNOSTICS is wrong from
Peter's reading of SQL92, and mine too.
> Bruce Momjian writes:
>
> > > Bruce Momjian writes:
> > >
> > > > New PL/pgSQL GET DIAGNOSTICS statement for SPI value access (Jan)
> > >
> > > If someone can show me an example of how i
[ Charset ISO-8859-1 unsupported, converting... ]
> > As you can see from the current open items list, there isn't much left
> > to do for the 7.1 release. I am going to suggest we remove the LAZY
> > VACUUM option at this point. I know Tom Lane posted an item about the
>
> Well, leaving for va
> As you can see from the current open items list, there isn't much left
> to do for the 7.1 release. I am going to suggest we remove the LAZY
> VACUUM option at this point. I know Tom Lane posted an item about the
Well, leaving for vacation tomorrow I have to agree -:(
LAZY patch will be avail
> > Actually, I have something from Oliver Elphick called pg_controldata:
>
> Could you send it to me so that I can find out how he gets the
> LC_COLLATE
> and LC_CTYPE from backend (assuming it tells backend locale not cients)
> ?
>
> > $ pg_controldata
> > Log file id:
Bruce Momjian wrote:
>
> > Bruce Momjian wrote:
> >
> >
> > > P O S T G R E S Q L
> > >
> > > 7 . 1 O P E NI T E M S
> > >
> > > Current at ftp://candle.pha.pa.us/pub/postgresql/open_items.
> >
> > Any possibility of putting my getlocale into contrib ?
> >
> > I agree that it should in fact
> Bruce Momjian wrote:
>
>
> > P O S T G R E S Q L
> >
> > 7 . 1 O P E NI T E M S
> >
> > Current at ftp://candle.pha.pa.us/pub/postgresql/open_items.
>
> Any possibility of putting my getlocale into contrib ?
>
> I agree that it should in fact be in the pg_locale.c but that would be a
Bruce Momjian wrote:
> P O S T G R E S Q L
>
> 7 . 1 O P E NI T E M S
>
> Current at ftp://candle.pha.pa.us/pub/postgresql/open_items.
Any possibility of putting my getlocale into contrib ?
I agree that it should in fact be in the pg_locale.c but that would be a
feature and we don't add
Bruce Momjian writes:
> > Bruce Momjian writes:
> >
> > > New PL/pgSQL GET DIAGNOSTICS statement for SPI value access (Jan)
> >
> > If someone can show me an example of how it operates I can write up
> > something.
>
> I found:
>
> > Quoting a recent message by Jan Wieck <[EMAIL PROTECTED]>:
>
> Bruce Momjian writes:
>
> > New PL/pgSQL GET DIAGNOSTICS statement for SPI value access (Jan)
>
> If someone can show me an example of how it operates I can write up
> something.
I found:
> Quoting a recent message by Jan Wieck <[EMAIL PROTECTED]>:
> :Do a
> :
> :GET DIAGNOSTICS
Bruce Momjian writes:
> New PL/pgSQL GET DIAGNOSTICS statement for SPI value access (Jan)
If someone can show me an example of how it operates I can write up
something.
> Improve PL/PgSQL documentation (?)
I agree with the "(?)"... Certainly a bit late to start an "improvement"
project.
> St
As you can see from the current open items list, there isn't much left
to do for the 7.1 release. I am going to suggest we remove the LAZY
VACUUM option at this point. I know Tom Lane posted an item about the
join visibility issue, so hopefully this can be resolved soon. Not sure
what to do abo
I have removed the following open item by adding the other mysql
conversion utility to the CVS tree in /contrib/mysql:
Merge MySQL/PgSQL translation scripts
If someone wants to merge them and make one script out of them, go
ahead. Both are BSD licensed now.
The only remaining source co
Items removed. Thanks.
> > separate client- and server-side includes, make optional install
> > target to install all of src/include
>
> This is done now, at least as far as the source tree goes (dunno
> how Lamar plans to handle it in the RPMs).
>
> > New file format for COPY BINARY (Tom)
> separate client- and server-side includes, make optional install
> target to install all of src/include
This is done now, at least as far as the source tree goes (dunno
how Lamar plans to handle it in the RPMs).
> New file format for COPY BINARY (Tom)
Already documented, see COPY reference
> At 12:26 9/02/01 -0500, Bruce Momjian wrote:
> >Overhaul pg_dump (Philip Warner)
> >New pg_dump tar output option (Philip)
> >New pg_dump of large objects (Philip)
> >New pg_restore command (Philip)
>
> The SGML docs for these have been there for a while - is there something
> else I need to d
At 12:26 9/02/01 -0500, Bruce Momjian wrote:
>Overhaul pg_dump (Philip Warner)
>New pg_dump tar output option (Philip)
>New pg_dump of large objects (Philip)
>New pg_restore command (Philip)
The SGML docs for these have been there for a while - is there something
else I need to do?
---
I have no idea. If we mention the existance of separate large object
files, they it has to be updated. If we don't mention it, then we can
remove the item.
[ Charset ISO-8859-1 unsupported, converting... ]
> > Store all large objects in a single table (Denis Perchine, Tom)
>
> Hmmm... If you
> Store all large objects in a single table (Denis Perchine, Tom)
Hmmm... If you would point me to the document where changes should be done, I
will do them.
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Attached is a list of open source code and documentation items for 7.1.
I've got two major TODO items that are not in your list, but should be:
* visibility of joined columns in JOIN clauses (Thomas thinks code is
wrong, I'm not sure yet)
* separate
Attached is a list of open source code and documentation items for 7.1.
If people can just confirm completed items, I will remove them right
away. The current version of this file can be seen at:
ftp://candle.pha.pa.us/pub/postgresql/open_items
-
Thanks, Peter. This is a big help.
> At 15:02 29/01/01 -0500, Bruce Momjian wrote:
> >LAZY VACUUM (Vadim)
> >Runtime btree recovery (Vadim)
> >JDBC setMaxRows() is global variable affecting other objects
>
> Now fixed. When called from within a Statement it uses its maxrows value,
> but inter
At 15:02 29/01/01 -0500, Bruce Momjian wrote:
>LAZY VACUUM (Vadim)
>Runtime btree recovery (Vadim)
>JDBC setMaxRows() is global variable affecting other objects
Now fixed. When called from within a Statement it uses its maxrows value,
but internal queries don't have a restriction.
>JDBC LargeOb
> * Bruce Momjian <[EMAIL PROTECTED]> [010129 14:40]:
> > > * Bruce Momjian <[EMAIL PROTECTED]> [010129 14:03]:
> > > > Fix ipcclean on Linux
> > > I believe Peter_E handled the above last week
> >
> > All I see is below, and the diff -c shows just the grep change.
> I thought that was all th
* Bruce Momjian <[EMAIL PROTECTED]> [010129 14:40]:
> > * Bruce Momjian <[EMAIL PROTECTED]> [010129 14:03]:
> > > Fix ipcclean on Linux
> > I believe Peter_E handled the above last week
>
> All I see is below, and the diff -c shows just the grep change.
I thought that was all that was crabbed
> * Bruce Momjian <[EMAIL PROTECTED]> [010129 14:03]:
> > Fix ipcclean on Linux
> I believe Peter_E handled the above last week
All I see is below, and the diff -c shows just the grep change.
---
revision 1.7
date: 2001
* Bruce Momjian <[EMAIL PROTECTED]> [010129 14:03]:
> Fix ipcclean on Linux
I believe Peter_E handled the above last week
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Ga
LAZY VACUUM (Vadim)
Runtime btree recovery (Vadim)
JDBC setMaxRows() is global variable affecting other objects
JDBC LargeObject short read return value missing
ODBC not disconnecting properly?
Merge MySQL/PgSQL translation scripts
Fix ipcclean on Linux
unixODBC
--
Bruce Momjian
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Thanks. BTW, are you going to make a back patch for the 7.0.x tree?
> I'm sure we are going to have lots of complaints from users who are
> developing their own user defined functions and about to use pg_dump
> to upgrade to 7.1 after it is officially rel
> >> Also I'm not quite sure "#arg" (stringification) is
> >> portable enough in all platforms.)
>
> > The patch looks fine to me, but I have no idea how portable #arg is
>
> Use the CppAsString macro from our c.h ... that's what it's for.
>
> It's actually fairly unlikely that anyone still u
> >Ok. I have made patches for fixing some of pg_dump problems(see
> >attached patches). The patches address the problem with user defined
> >functions, operators and aggregates.
>
> These have now been applied with minor modifications.
Thanks. BTW, are you going to make a back patch for the 7.
Hi, there!
On Sat, 27 Jan 2001, Bruce Momjian wrote:
> Here are the open items for 7.1. Much shorter:
>
> Reorder INSERT firing in rules
> JDBC LargeObject short read return value missing
> LAZY VACUUM
> JDBC setMaxRows() is global variable affecting other objects
> Fix for pg_dump of bad syst
At 23:14 27/01/01 -0500, Bruce Momjian wrote:
>I assume this addresses the open item:
>
> Fix for pg_dump of bad system tables
>
>I will remove it from the list. Thanks.
>
I'd remove it from the 'Required for 7.1' list, but leave it on the TODO
list, since the task is not quite complete.
> At 23:14 27/01/01 -0500, Bruce Momjian wrote:
> >I assume this addresses the open item:
> >
> > Fix for pg_dump of bad system tables
> >
> >I will remove it from the list. Thanks.
> >
>
> I'd remove it from the 'Required for 7.1' list, but leave it on the TODO
> list, since the task is not
I assume this addresses the open item:
Fix for pg_dump of bad system tables
I will remove it from the list. Thanks.
> At 07:24 26/01/01 +0900, Tatsuo Ishii wrote:
> >> Fix for pg_dump of bad system tables
> >
> >Ok. I have made patches for fixing some of pg_dump problems(see
> >attac
At 07:24 26/01/01 +0900, Tatsuo Ishii wrote:
>> Fix for pg_dump of bad system tables
>
>Ok. I have made patches for fixing some of pg_dump problems(see
>attached patches). The patches address the problem with user defined
>functions, operators and aggregates.
These have now been applied with min
Philip Warner <[EMAIL PROTECTED]> writes:
>> Also I'm not quite sure "#arg" (stringification) is
>> portable enough in all platforms.)
> The patch looks fine to me, but I have no idea how portable #arg is
Use the CppAsString macro from our c.h ... that's what it's for.
It's actually fairly un
At 07:24 26/01/01 +0900, Tatsuo Ishii wrote:
>> Fix for pg_dump of bad system tables
>
>Ok. I have made patches for fixing some of pg_dump problems(see
>attached patches).
...
>Also I'm not quite sure "#arg" (stringification) is
>portable enough in all platforms.)
The patch looks fine to me, b
> Here are the open items for 7.1. Much shorter:
+ Runtime btree recovery
Vadim
Here are the open items for 7.1. Much shorter:
Reorder INSERT firing in rules
JDBC LargeObject short read return value missing
LAZY VACUUM
JDBC setMaxRows() is global variable affecting other objects
Fix for pg_dump of bad system tables
ODBC not disconnecting properly?
Magnus Hagander ODBC issue
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"
>>
>> A well known issue, and I've asked multiple times how exactly
>> we want to define the behaviour for deferred constraints. Do
>> foreign keys reference just to a key v
> Bruce Momjian writes:
>
> > FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"
>
> You're certainly not going to want to fix this now after having stared at
> it for a year? It's not trivial.
Moved to TODO.
>
> > Usernames limited in length
>
> Yeah, they are. ;-)
>
> I
Bruce Momjian <[EMAIL PROTECTED]> writes:
> SELECT cash_out(1) crashes all backends
>>
> OK, removed from 'open' list and added to TODO. Actually, I can't get
> the crash to happen except with cash_out. Is there another *out
> function you can get to fail.
Any pass-by-reference type; also mos
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Here are my open 7.1 items. Thanks for shrinking the list so far.
>
> > SELECT cash_out(1) crashes all backends
>
OK, removed from 'open' list and added to TODO. Actually, I can't get
the crash to happen except with cash_out. Is there another *
Jan Wieck <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> Reorder INSERT firing in rules
> I don't recall why this is wanted. AFAIK there's no reason
> NOT to do so, except for the actual state of beeing far too
> close to a release candidate.
I think I've been the main pe
> > FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"
>
> A well known issue, and I've asked multiple times how exactly
> we want to define the behaviour for deferred constraints. Do
> foreign keys reference just to a key value and are happy with
> it's existan
> > FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"
>
> A well known issue, and I've asked multiple times how exactly
> we want to define the behaviour for deferred constraints. Do
> foreign keys reference just to a key value and are happy with
> it's exista
Bruce Momjian wrote:
> Here are my open 7.1 items. Thanks for shrinking the list so far.
>
> ---
>
> FreeBSD locale bug
> Reorder INSERT firing in rules
I don't recall why this is wanted. AFAIK there's no reason
N
Hiroshi Inoue writes:
> What does this item mean ?
> Is it the following ?
>
> begin;
> insert into pk (id) values (1);
> update(delete from) pk where id=1;
> ERROR: triggered data change violation on relation pk"
>
> If so, isn't it a simple bug ?
Depends on the definit
Sorry for my previous incomplete posting.
Peter Eisentraut wrote:
>
> Bruce Momjian writes:
>
> > FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"
>
> You're certainly not going to want to fix this now after having stared at
> it for a year? It's not trivial.
>
What does
Peter Eisentraut wrote:
>
> Bruce Momjian writes:
>
> > FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"
>
> You're certainly not going to want to fix this now after having stared at
> it for a year? It's not trivial.
>
What does this item mean ?
> > Usernames limited in
> Fix for pg_dump of bad system tables
Ok. I have made patches for fixing some of pg_dump problems(see
attached patches). The patches address the problem with user defined
functions, operators and aggregates. Could someone please review and
commit them if they look ok? (I'm now in US and have on
Bruce Momjian writes:
> FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"
You're certainly not going to want to fix this now after having stared at
it for a year? It's not trivial.
> Usernames limited in length
Yeah, they are. ;-)
If this is referring to pg_passwd, I just
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Here are my open 7.1 items. Thanks for shrinking the list so far.
> SELECT cash_out(1) crashes all backends
This isn't a "must fix for 7.1", any more than it was for 7.0, 6.5,
or any other release back to the beginning of time. It's always been
possi
Quoting Bruce Momjian <[EMAIL PROTECTED]>:
> I have trickled the emails as I reviewed them, asking for comments. It
> was not one big email.
I haven't seen them either, although my Inbox is big again, and I'm filtering
out mails by their subject line, so it's possible I've missed them.
I'm sl
On Wed, 24 Jan 2001, Bruce Momjian wrote:
> Here are my open 7.1 items. Thanks for shrinking the list so far.
>
> ---
>
> FreeBSD locale bug
AFAIK, Tom have fixed it, if this bug is about -funsigned-char
> Reorder INSERT f
Here are my open 7.1 items. Thanks for shrinking the list so far.
---
FreeBSD locale bug
Reorder INSERT firing in rules
Philip Warner UPDATE crash
JDBC LargeObject short read return value missing
SELECT cash_out(1) crashes
On Wed, 24 Jan 2001, Hannu Krosing wrote:
> Bruce Momjian wrote:
> >
> > > You can't reasonably expect people to read all e-mail from last few
> > > weeks
> > > (probably a few thousands) and spot the same items as you.
> > >
> > > > May as well read the email rather than link to a web page.
> >
> On Wed, 24 Jan 2001, Hannu Krosing wrote:
>
> > Bruce Momjian wrote:
> > >
> > > > You can't reasonably expect people to read all e-mail from last few
> > > > weeks
> > > > (probably a few thousands) and spot the same items as you.
> > > >
> > > > > May as well read the email rather than link t
Bruce Momjian wrote:
>
> > You can't reasonably expect people to read all e-mail from last few
> > weeks
> > (probably a few thousands) and spot the same items as you.
> >
> > > May as well read the email rather than link to a web page.
> >
> > Still it would be good to have a "TODO before 7.1 re
> You can't reasonably expect people to read all e-mail from last few
> weeks
> (probably a few thousands) and spot the same items as you.
>
> > May as well read the email rather than link to a web page.
>
> Still it would be good to have a "TODO before 7.1 relese"
I send each article to the ap
Bruce Momjian wrote:
>
> > On Wed, 24 Jan 2001, Bruce Momjian wrote:
> >
> > > > > It has to be done separately because you need to see the full content
> > > > > and reply to each individually. Also, they go to different lists
> > > > > sometimes. Pretty confusing.
> > > >
> > > > Could you po
> > It has to be done separately because you need to see the full content
> > and reply to each individually. Also, they go to different lists
> > sometimes. Pretty confusing.
>
> Could you post a list of open issues where each has just a number,
> heading
> (optional) and link to an email in
> > > > They can not be easily summarized in one line. You really have to see
> > > > the whole email to understand the issues.
> > > >
> > > > How do people want to do this? I can post them to hackers, or put them
> > > > on my web site. I posted them to hackers during the past few days, but
>
On Wed, 24 Jan 2001, Bruce Momjian wrote:
> > > It has to be done separately because you need to see the full content
> > > and reply to each individually. Also, they go to different lists
> > > sometimes. Pretty confusing.
> >
> > Could you post a list of open issues where each has just a numb
Bruce Momjian wrote:
>
> > > > > They can not be easily summarized in one line. You really have to see
> > > > > the whole email to understand the issues.
> > > > >
> > > > > How do people want to do this? I can post them to hackers, or put them
> > > > > on my web site. I posted them to hacke
Bruce Momjian wrote:
>
> I have trickled the emails as I reviewed them, asking for comments. It
> was not one big email.
...
> > > They can not be easily summarized in one line. You really have to see
> > > the whole email to understand the issues.
> > >
> > > How do people want to do this?
> On Wed, 24 Jan 2001, Bruce Momjian wrote:
>
> > > > It has to be done separately because you need to see the full content
> > > > and reply to each individually. Also, they go to different lists
> > > > sometimes. Pretty confusing.
> > >
> > > Could you post a list of open issues where each h
I have trickled the emails as I reviewed them, asking for comments. It
was not one big email.
>
> haven't seen it posted to hackers, or, if I did, I didn't clue into it ...
> and just checked to see if maybe it was waiting for approval due to size,
> and nothing in the queue ...
>
> posting it
haven't seen it posted to hackers, or, if I did, I didn't clue into it ...
and just checked to see if maybe it was waiting for approval due to size,
and nothing in the queue ...
posting it here is easier to respond to ...
On Wed, 24 Jan 2001, Bruce Momjian wrote:
> I have about 20 open 7.1 it
I have about 20 open 7.1 items that I need to get resolved before I can
start getting the doc TODO list started. The issues relate to JDBC,
ODBC, and lots of other stuff that need to be settled before we can
finalize 7.1.
They can not be easily summarized in one line. You really have to see
the
93 matches
Mail list logo
