Thread:
Hi,
This is the first posting to the community of the WIP patch for the Updatable Cursor implementation.
I want to confirm that the community is satisfied that the effort to date is in a suitable direction and to get comments on the development to date.
The patch is in the following state:
The grammar definition is complete and 'yacc'ed to produce gram.y.c.
The functions transformUpdateStmt and transformDeleteStmt have been updated to process the cursor name and obtain the related portal.
The change to save the current tuple id (ctid) into the portal, related to the Fetch command has been done.
The ctids relating to the Update/Delete statements' TidScan are being extracted to be saved in the executor.
The parts in progress are to complete the saving of the ctids from the TidScan into a list stored in a file, plus related searching the list for an individual ctid obtained from the Update/Delete statements.
Unstarted as yet:
1) Correctly process, in the database, the Delete / Update of the tuple from the cursor.
2) To enable the cursor name to be defined as a parameter in a PREPARE statement and provided as part if an EXECUTE statement.
The community may wish to comment on the following issue:
1) At present the file that will contain the list of ctids is going into a new directory called pg_ctids, analogous to pg_twophase, and also stored in the pg_data directory.
Regards,
John Bartlett
This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you. If you do not wish to receive commercial email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscribe@fast.fujitsu.com.au |
Attachment
John Bartlett wrote: > The community may wish to comment on the following issue: > > 1) At present the file that will contain the list of ctids is going into > a new directory called pg_ctids, analogous to pg_twophase, and also stored > in the pg_data directory. I don't understand this. What's stored in the file and why? If they're only needed within the transaction, surely a temp file would be more appropriate? The new ctidListStore.c file in the patch is not in a valid diff-format. I also noticed that you've moved the line beginning with "CREATE_ROLE" in gram.y so that it's not in alphabetical order anymore. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
FYI, I am not going to be comfortable accepting a final patch that
contains this email signature:
This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN
27 003 693 481. It is confidential to the ordinary user of the email
address to which it was addressed and may contain copyright and/or
---------------------
legally privileged information. No one else may read, print, store, copy
or forward all or any of it or its attachments. If you receive this
email in error, please return to s ender. Thank you.
unless you provide additional details on your contribution of this code
under a BSD license.
---------------------------------------------------------------------------
John Bartlett wrote:
> Hi,
>
>
>
> This is the first posting to the community of the WIP patch for the
> Updatable Cursor implementation.
>
>
>
> I want to confirm that the community is satisfied that the effort to date is
> in a suitable direction and to get comments on the development to date.
>
>
>
> The patch is in the following state:
>
>
>
> The grammar definition is complete and 'yacc'ed to produce gram.y.c.
>
>
>
> The functions transformUpdateStmt and transformDeleteStmt have been updated
> to process the cursor name and obtain the related portal.
>
>
>
> The change to save the current tuple id (ctid) into the portal, related to
> the Fetch command has been done.
>
>
>
> The ctids relating to the Update/Delete statements' TidScan are being
> extracted to be saved in the executor.
>
>
>
> The parts in progress are to complete the saving of the ctids from the
> TidScan into a list stored in a file, plus related searching the list for an
> individual ctid obtained from the Update/Delete statements.
>
>
>
> Unstarted as yet:
>
>
>
> 1) Correctly process, in the database, the Delete / Update of the
> tuple from the cursor.
>
> 2) To enable the cursor name to be defined as a parameter in a
> PREPARE statement and provided as part if an EXECUTE statement.
>
>
>
> The community may wish to comment on the following issue:
>
>
>
> 1) At present the file that will contain the list of ctids is going into
> a new directory called pg_ctids, analogous to pg_twophase, and also stored
> in the pg_data directory.
>
>
>
> Regards,
> John Bartlett
>
> This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the
ordinaryuser of the email address to which it was addressed and may contain copyright and/or legally privileged
information.No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive
thisemail in error, please return to sender. Thank you.
>
> If you do not wish to receive commercial email messages from Fujitsu Australia Software Technology Pty Ltd, please
emailunsubscribe@fast.fujitsu.com.au
[ Attachment, skipping... ]
>
> ---------------------------(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
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote:
> FYI, I am not going to be comfortable accepting a final patch that
> contains this email signature:
>
> This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN
> 27 003 693 481. It is confidential to the ordinary user of the email
> address to which it was addressed and may contain copyright and/or
> ---------------------
> legally privileged information. No one else may read, print, store, copy
> or forward all or any of it or its attachments. If you receive this
> email in error, please return to s ender. Thank you.
>
> unless you provide additional details on your contribution of this code
> under a BSD license.
Gonna have to concur with that. Not that the sig is legally binding
anyway, we do need to have a disclaimer in the email stating that you
are assigning to PGDG>
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
On Tue, 2007-02-27 at 14:52 -0800, Joshua D. Drake wrote: > Gonna have to concur with that. Not that the sig is legally binding > anyway, we do need to have a disclaimer in the email stating that you > are assigning to PGDG I think it's pretty silly to start caring about this now. Do you think that in the absence of any signature/disclaimer attached to a patch, then the copyright for the change is "implicitly" assigned to PGDG? (I'm not a lawyer, but I believe that's not the case.) -Neil
Neil Conway wrote: > On Tue, 2007-02-27 at 14:52 -0800, Joshua D. Drake wrote: > > Gonna have to concur with that. Not that the sig is legally binding > > anyway, we do need to have a disclaimer in the email stating that you > > are assigning to PGDG > > I think it's pretty silly to start caring about this now. Do you think > that in the absence of any signature/disclaimer attached to a patch, > then the copyright for the change is "implicitly" assigned to PGDG? (I'm > not a lawyer, but I believe that's not the case.) I think the issue is _explicit_ vs _implicit_. I think the email signature was too explicit. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Neil Conway wrote:
> On Tue, 2007-02-27 at 14:52 -0800, Joshua D. Drake wrote:
>> Gonna have to concur with that. Not that the sig is legally binding
>> anyway, we do need to have a disclaimer in the email stating that you
>> are assigning to PGDG
>
> I think it's pretty silly to start caring about this now. Do you think
> that in the absence of any signature/disclaimer attached to a patch,
> then the copyright for the change is "implicitly" assigned to PGDG? (I'm
> not a lawyer, but I believe that's not the case.)
I can tell you that it depends on the individuals relationship with
their employer. The employer may have agreement (most do) that will
state that whatever the employee does is owned by the employer.
Thus we may literally not have rights to the code. Do you really want to
go down the path of in 2 years, Fujitsu (No offense Fujitsu), but you
are the topic) decides that the code they provided is owned by them and
they didn't give us permission?
Joshua D. Drake
>
> -Neil
>
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
On Tue, 2007-02-27 at 16:20 -0800, Joshua D. Drake wrote: > Thus we may literally not have rights to the code. Do you really want to > go down the path of in 2 years, Fujitsu (No offense Fujitsu), but you > are the topic) decides that the code they provided is owned by them and > they didn't give us permission? For the case in question, sure, requiring some clarification from FJ would be reasonable. But more broadly, my point is that I think you're fooling yourself if you think that requiring a disclaimer or explicit transfer of copyright for this *one* particular patch is likely to make any material difference to the overall copyright status of the code base. -Neil
Neil Conway wrote: > On Tue, 2007-02-27 at 16:20 -0800, Joshua D. Drake wrote: > > Thus we may literally not have rights to the code. Do you really want to > > go down the path of in 2 years, Fujitsu (No offense Fujitsu), but you > > are the topic) decides that the code they provided is owned by them and > > they didn't give us permission? > > For the case in question, sure, requiring some clarification from FJ > would be reasonable. But more broadly, my point is that I think you're > fooling yourself if you think that requiring a disclaimer or explicit > transfer of copyright for this *one* particular patch is likely to make > any material difference to the overall copyright status of the code > base. Yes, I do. If there is an explicit claim, like an email footer or a copyright in the code, we do try to nail that down. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Hi, A list of ctids is stored in the file. The file is used to store the ctids during an updatable cursor transaction. It is set up as a permanent file as it has a potential lifetime of preserving data between crashes of the backend. Temporary files tend to be used for data that is defined within a single command. In this case the file needs to exist within a transaction and across backend processes. The file gram.y has been corrected in my version. The files ctidListStore.c and ctidListStore.h were pasted into the patch file, as the diff -N command produced a file of several hundred thousand lines. Regards, John Bartlett -----Original Message----- From: Heikki Linnakangas [mailto:hlinnaka@gmail.com] On Behalf Of Heikki Linnakangas Sent: Tuesday, 27 February 2007 10:03 PM To: John Bartlett Cc: pgsql-patches@postgresql.org; pgsql-hackers@postgresql.org Subject: Re: [PATCHES] John Bartlett wrote: > The community may wish to comment on the following issue: > > 1) At present the file that will contain the list of ctids is going into > a new directory called pg_ctids, analogous to pg_twophase, and also stored > in the pg_data directory. I don't understand this. What's stored in the file and why? If they're only needed within the transaction, surely a temp file would be more appropriate? The new ctidListStore.c file in the patch is not in a valid diff-format. I also noticed that you've moved the line beginning with "CREATE_ROLE" in gram.y so that it's not in alphabetical order anymore. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the ordinaryuser of the email address to which it was addressed and may contain copyright and/or legally privileged information.No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive thisemail in error, please return to sender. Thank you. If you do not wish to receive commercial email messages from Fujitsu Australia Software Technology Pty Ltd, please emailunsubscribe@fast.fujitsu.com.au
On Wed, 28 Feb 2007 09:48, Bruce Momjian wrote: [Added a subejct line] > FYI, I am not going to be comfortable accepting a final patch that > contains this email signature: > > This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN > 27 003 693 481. It is confidential to the ordinary user of the email > address to which it was addressed and may contain copyright and/or > --------------------- > legally privileged information. No one else may read, print, store, copy > or forward all or any of it or its attachments. If you receive this > email in error, please return to s ender. Thank you. > > unless you provide additional details on your contribution of this code > under a BSD license. We are happy to provide that. If and when it comes to the final patch being accepted, we can send a copyright waiver mail which will put our source code contribution under the BSD license. Rgds, Arul Shaji > > --------------------------------------------------------------------------- > > John Bartlett wrote: > > Hi, > > > > > > > > This is the first posting to the community of the WIP patch for the > > Updatable Cursor implementation. > > > > > > > > I want to confirm that the community is satisfied that the effort to date > > is in a suitable direction and to get comments on the development to > > date. > > > > > > > > The patch is in the following state: > > > > > > > > The grammar definition is complete and 'yacc'ed to produce gram.y.c. > > > > > > > > The functions transformUpdateStmt and transformDeleteStmt have been > > updated to process the cursor name and obtain the related portal. > > > > > > > > The change to save the current tuple id (ctid) into the portal, related > > to the Fetch command has been done. > > > > > > > > The ctids relating to the Update/Delete statements' TidScan are being > > extracted to be saved in the executor. > > > > > > > > The parts in progress are to complete the saving of the ctids from the > > TidScan into a list stored in a file, plus related searching the list for > > an individual ctid obtained from the Update/Delete statements. > > > > > > > > Unstarted as yet: > > > > > > > > 1) Correctly process, in the database, the Delete / Update of > > the tuple from the cursor. > > > > 2) To enable the cursor name to be defined as a parameter in a > > PREPARE statement and provided as part if an EXECUTE statement. > > > > > > > > The community may wish to comment on the following issue: > > > > > > > > 1) At present the file that will contain the list of ctids is going > > into a new directory called pg_ctids, analogous to pg_twophase, and also > > stored in the pg_data directory. > > > > > > > > Regards, > > John Bartlett > > > > This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN > > 27 003 693 481. It is confidential to the ordinary user of the email > > address to which it was addressed and may contain copyright and/or > > legally privileged information. No one else may read, print, store, copy > > or forward all or any of it or its attachments. If you receive this email > > in error, please return to sender. Thank you. > > > > If you do not wish to receive commercial email messages from Fujitsu > > Australia Software Technology Pty Ltd, please email > > unsubscribe@fast.fujitsu.com.au > > [ Attachment, skipping... ] > > > ---------------------------(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 This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the ordinaryuser of the email address to which it was addressed and may contain copyright and/or legally privileged information.No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive thisemail in error, please return to sender. Thank you. If you do not wish to receive commercial email messages from Fujitsu Australia Software Technology Pty Ltd, please emailunsubscribe@fast.fujitsu.com.au
On Wed, 28 Feb 2007, John Bartlett wrote: > Hi, > > A list of ctids is stored in the file. I would have thought these would be stored in memory. If the set got large, you'd use a temporary file the way other systems which overflow to disk do? > > The file is used to store the ctids during an updatable cursor transaction. > > It is set up as a permanent file as it has a potential lifetime of > preserving data between crashes of the backend. Temporary files tend to be > used for data that is defined within a single command. In this case the file > needs to exist within a transaction and across backend processes. It does not. Cursors are implicitly closed when a session is closed. A backend crash or system restart closes all open sessions. > > The file gram.y has been corrected in my version. > > The files ctidListStore.c and ctidListStore.h were pasted into the patch > file, as the diff -N command produced a file of several hundred thousand > lines. Edit the file with a text editor. If you know which files should be excluded (like tags files), use diff --exclude=<pattern>. Thanks, Gavin
Bruce Momjian <bruce@momjian.us> writes:
> Neil Conway wrote:
>> For the case in question, sure, requiring some clarification from FJ
>> would be reasonable. But more broadly, my point is that I think you're
>> fooling yourself if you think that requiring a disclaimer or explicit
>> transfer of copyright for this *one* particular patch is likely to make
>> any material difference to the overall copyright status of the code
>> base.
> Yes, I do. If there is an explicit claim, like an email footer or a
> copyright in the code, we do try to nail that down.
AFAICT, the footer in question tries to make it illegal for us even to
have the message in our mail archives. If I were running the PG lists,
I would install filters that automatically reject mails containing such
notices, with a message like "Your corporate lawyers do not deserve to
have access to the internet. Go away until you've acquired a clue."
I fully support Bruce's demand that patches be submitted with no such
idiocy attached.
regards, tom lane
>> Yes, I do. If there is an explicit claim, like an email footer or a >> copyright in the code, we do try to nail that down. > > AFAICT, the footer in question tries to make it illegal for us even to > have the message in our mail archives. If I were running the PG lists, > I would install filters that automatically reject mails containing such > notices, with a message like "Your corporate lawyers do not deserve to > have access to the internet. Go away until you've acquired a clue." Well that would pretty much eliminate the ability to receive mail from any large company :) but I can certainly appreciate the sentiment. > > I fully support Bruce's demand that patches be submitted with no such > idiocy attached. Absolutely. In regards to your idea of a filter, there is no reason why we couldn't install a filter that checks for signatures with specific legal words and strips said signature automatically, responding to the sender that we did so. Joshua D. Drake > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/
"Joshua D. Drake" <jd@commandprompt.com> writes:
> ... In regards to your idea of a filter, there is no reason why
> we couldn't install a filter that checks for signatures with specific
> legal words and strips said signature automatically, responding to the
> sender that we did so.
The problem is that if $SENDER's corporate lawyers actually think that
it means something to put a restriction-of-rights notice on a message
sent to a public mailing list, then they might think that posting the
message with the notice stripped represents a violation of their barren
intellectual property :-(. What I'd like us to do is bounce it back.
A slightly cleaner version of the notice might be "If you wish to post
this message on our worldwide mailing lists, and thereby make unrepaid
use of our redistribution and archiving resources, then you may not
assert the right to restrict redistribution of your message."
Not that I think that anyone owning both a law degree and a computer
in 2007 should legitimately be able to plead innocence here. FAST
Australia's lawyers are making themselves look like idiots, and the
same for every other company tacking on such notices. I think the
real bottom line here is "we don't accept patches from idiots".
regards, tom lane
> Not that I think that anyone owning both a law degree and a computer
> in 2007 should legitimately be able to plead innocence here. FAST
> Australia's lawyers are making themselves look like idiots, and the
> same for every other company tacking on such notices. I think the
> real bottom line here is "we don't accept patches from idiots".
Well the problem is, it isn't the guy that sent the patch that is the
idiot. That guys has zero control over the matter, the signature is
going to be tacked on at the MTA level.
I talked to my attorneys about this problem (not specific to postgresql
but in general) because my CPAs also have the same type of notice.
My attorney's response was that it is all about disclosure and covering
your butt. Not ours, but theirs. The idea being that they can say, "Look
we sent out the confidential disclosure, it isn't our fault the
recipients didn't listen."
Of course the joke here is, that the email went out on a public list and
is now mirrored all over the world and harvested by every spammer on the
planet ;)
However, it may be a good idea to have our (SPI) attorney at least give
us an official word on the matter. Thoughts?
Sincerely,
Joshua D. Drake
>
> regards, tom lane
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: >> ... In regards to your idea of a filter, there is no reason why >> we couldn't install a filter that checks for signatures with specific >> legal words and strips said signature automatically, responding to the >> sender that we did so. > > The problem is that if $SENDER's corporate lawyers actually think that > it means something to put a restriction-of-rights notice on a message > sent to a public mailing list, then they might think that posting the > message with the notice stripped represents a violation of their barren > intellectual property :-(. What I'd like us to do is bounce it back. > A slightly cleaner version of the notice might be "If you wish to post > this message on our worldwide mailing lists, and thereby make unrepaid > use of our redistribution and archiving resources, then you may not > assert the right to restrict redistribution of your message." > > Not that I think that anyone owning both a law degree and a computer > in 2007 should legitimately be able to plead innocence here. FAST > Australia's lawyers are making themselves look like idiots, and the > same for every other company tacking on such notices. I think the > real bottom line here is "we don't accept patches from idiots". I think "we don't accept patches from idiots" is a bit harsh. There are quite a few skilled developers out there working for large companies that are not doing most of their day-to-day business with OSS software(and therefor know how to interact with the community). Working in such a large environment requires one to use the tools and infrastructure provided by the company - while I fully agree that email sigs are one of the more stupid things it is often something the individual person might not even know about (gets added at the gateway) or can do much about it. Stefan
"Joshua D. Drake" <jd@commandprompt.com> writes:
> Well the problem is, it isn't the guy that sent the patch that is the
> idiot. That guys has zero control over the matter, the signature is
> going to be tacked on at the MTA level.
Sure, I know that and you know that. The problem we have to worry about
is that some PHB might later decide to sue us based on our having
ignored the pasted-on disclaimer. Now either the disclaimer means
something, in which case we had better cover our own butts by not
putting a restricted communication into our archives; or else it means
nothing, in which case the submitter can perfectly well resubmit it
without. But the present situation in which we accept and repost
messages containing these sorts of restrictions is the worst of all
possible worlds, because *we* can get sued if anyone is unhappy. Now
that is exactly the result desired by your standard corporate lawyer;
he's been trained to shift blame off his company onto any available
target. But I say it's not necessary, wise, nor moral for us to accept
such liability.
As to the original point, though: if the guy who sent the patch cannot
control the legalistic notices appended to his email, we must surely
not suppose that he has legal ownership of his work product. We need
a certification from his corporate lawyers that they won't sue us for
accepting the patch. If they don't feel the need for such formalities,
they should signal the world by not appending dam-fool notices to every
outgoing email.
regards, tom lane
> Not that I think that anyone owning both a law degree and a computer > in 2007 should legitimately be able to plead innocence here. FAST > Australia's lawyers are making themselves look like idiots, and the > same for every other company tacking on such notices. I think the > real bottom line here is "we don't accept patches from idiots". I think "we don't accept patches from idiots" is a bit harsh.
I agree, after all, you've accepted some of my patches and... oh, wait...
-- Korry
I have added this to the developer's FAQ to clarify the situtation of
posting a patch:
<li>PostgreSQL is licensed under a BSD license. By posting a patch
to the public PostgreSQL mailling lists, you are giving the PostgreSQL
Global Development Group the non-revokable right to distribute your
patch under the BSD license. If you use code that is available under
some other license that is BSD compatible (eg. public domain), please
note that in your email submission.</li>
---------------------------------------------------------------------------
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Neil Conway wrote:
> >> For the case in question, sure, requiring some clarification from FJ
> >> would be reasonable. But more broadly, my point is that I think you're
> >> fooling yourself if you think that requiring a disclaimer or explicit
> >> transfer of copyright for this *one* particular patch is likely to make
> >> any material difference to the overall copyright status of the code
> >> base.
>
> > Yes, I do. If there is an explicit claim, like an email footer or a
> > copyright in the code, we do try to nail that down.
>
> AFAICT, the footer in question tries to make it illegal for us even to
> have the message in our mail archives. If I were running the PG lists,
> I would install filters that automatically reject mails containing such
> notices, with a message like "Your corporate lawyers do not deserve to
> have access to the internet. Go away until you've acquired a clue."
>
> I fully support Bruce's demand that patches be submitted with no such
> idiocy attached.
>
> regards, tom lane
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote:
> I have added this to the developer's FAQ to clarify the situtation of
> posting a patch:
>
> <li>PostgreSQL is licensed under a BSD license. By posting a patch
> to the public PostgreSQL mailling lists, you are giving the PostgreSQL
> Global Development Group the non-revokable right to distribute your
> patch under the BSD license. If you use code that is available under
> some other license that is BSD compatible (eg. public domain), please
> note that in your email submission.</li>
We should add this to the mailing list signup pages and the welcome
pages to the lists.
Joshua D. Drake
>
>
> ---------------------------------------------------------------------------
>
> Tom Lane wrote:
>> Bruce Momjian <bruce@momjian.us> writes:
>>> Neil Conway wrote:
>>>> For the case in question, sure, requiring some clarification from FJ
>>>> would be reasonable. But more broadly, my point is that I think you're
>>>> fooling yourself if you think that requiring a disclaimer or explicit
>>>> transfer of copyright for this *one* particular patch is likely to make
>>>> any material difference to the overall copyright status of the code
>>>> base.
>>> Yes, I do. If there is an explicit claim, like an email footer or a
>>> copyright in the code, we do try to nail that down.
>> AFAICT, the footer in question tries to make it illegal for us even to
>> have the message in our mail archives. If I were running the PG lists,
>> I would install filters that automatically reject mails containing such
>> notices, with a message like "Your corporate lawyers do not deserve to
>> have access to the internet. Go away until you've acquired a clue."
>>
>> I fully support Bruce's demand that patches be submitted with no such
>> idiocy attached.
>>
>> regards, tom lane
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
Joshua D. Drake wrote: > Bruce Momjian wrote: > > I have added this to the developer's FAQ to clarify the situtation of > > posting a patch: > > > > <li>PostgreSQL is licensed under a BSD license. By posting a patch > > to the public PostgreSQL mailling lists, you are giving the PostgreSQL > > Global Development Group the non-revokable right to distribute your > > patch under the BSD license. If you use code that is available under > > some other license that is BSD compatible (eg. public domain), please > > note that in your email submission.</li> > > > We should add this to the mailing list signup pages and the welcome > pages to the lists. Yep, good idea. Marc? --------------------------------------------------------------------------- > > Joshua D. Drake > > > > > > > > --------------------------------------------------------------------------- > > > > Tom Lane wrote: > >> Bruce Momjian <bruce@momjian.us> writes: > >>> Neil Conway wrote: > >>>> For the case in question, sure, requiring some clarification from FJ > >>>> would be reasonable. But more broadly, my point is that I think you're > >>>> fooling yourself if you think that requiring a disclaimer or explicit > >>>> transfer of copyright for this *one* particular patch is likely to make > >>>> any material difference to the overall copyright status of the code > >>>> base. > >>> Yes, I do. If there is an explicit claim, like an email footer or a > >>> copyright in the code, we do try to nail that down. > >> AFAICT, the footer in question tries to make it illegal for us even to > >> have the message in our mail archives. If I were running the PG lists, > >> I would install filters that automatically reject mails containing such > >> notices, with a message like "Your corporate lawyers do not deserve to > >> have access to the internet. Go away until you've acquired a clue." > >> > >> I fully support Bruce's demand that patches be submitted with no such > >> idiocy attached. > >> > >> regards, tom lane > > > > > -- > > === The PostgreSQL Company: Command Prompt, Inc. === > Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 > Providing the most comprehensive PostgreSQL solutions since 1997 > http://www.commandprompt.com/ > > Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate > PostgreSQL Replication: http://www.commandprompt.com/products/ -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
> Joshua D. Drake wrote:
>> We should add this to the mailing list signup pages and the welcome
>> pages to the lists.
> Yep, good idea. Marc?
For -patches and -hackers, I agree. It seems a bit legalistic and
off-putting for the general lists, though.
regards, tom lane
On Thu, 1 Mar 2007 04:28, Bruce Momjian wrote: > I have added this to the developer's FAQ to clarify the situtation of > posting a patch: > > <li>PostgreSQL is licensed under a BSD license. By posting a patch > to the public PostgreSQL mailling lists, you are giving the PostgreSQL > Global Development Group the non-revokable right to distribute your > patch under the BSD license. If you use code that is available under > some other license that is BSD compatible (eg. public domain), please > note that in your email submission.</li> > We are happy to do this for every patch we submit. We can add an explicit statement which will put our contribution under the BSD license. This statement will override the email signature and will be approved by the appropriate person. Rgds, Arul Shaji > > --------------------------------------------------------------------------- > > Tom Lane wrote: > > Bruce Momjian <bruce@momjian.us> writes: > > > Neil Conway wrote: > > >> For the case in question, sure, requiring some clarification from FJ > > >> would be reasonable. But more broadly, my point is that I think you're > > >> fooling yourself if you think that requiring a disclaimer or explicit > > >> transfer of copyright for this *one* particular patch is likely to > > >> make any material difference to the overall copyright status of the > > >> code base. > > > > > > Yes, I do. If there is an explicit claim, like an email footer or a > > > copyright in the code, we do try to nail that down. > > > > AFAICT, the footer in question tries to make it illegal for us even to > > have the message in our mail archives. If I were running the PG lists, > > I would install filters that automatically reject mails containing such > > notices, with a message like "Your corporate lawyers do not deserve to > > have access to the internet. Go away until you've acquired a clue." > > > > I fully support Bruce's demand that patches be submitted with no such > > idiocy attached. > > > > regards, tom lane This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the ordinaryuser of the email address to which it was addressed and may contain copyright and/or legally privileged information.No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive thisemail in error, please return to sender. Thank you. If you do not wish to receive commercial email messages from Fujitsu Australia Software Technology Pty Ltd, please emailunsubscribe@fast.fujitsu.com.au
FAST PostgreSQL wrote:
> On Thu, 1 Mar 2007 04:28, Bruce Momjian wrote:
>> I have added this to the developer's FAQ to clarify the situtation of
>> posting a patch:
>>
>> <li>PostgreSQL is licensed under a BSD license. By posting a patch
>> to the public PostgreSQL mailling lists, you are giving the PostgreSQL
>> Global Development Group the non-revokable right to distribute your
>> patch under the BSD license. If you use code that is available under
>> some other license that is BSD compatible (eg. public domain), please
>> note that in your email submission.</li>
>>
>
> We are happy to do this for every patch we submit. We can add an explicit
> statement which will put our contribution under the BSD license. This
> statement will override the email signature and will be approved by the
> appropriate person.
>
> Rgds,
> Arul Shaji
I know that I can speak for the community when I say, Thanks to you and
Fujitsu for taking our concerns into consideration.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
On Thu, 2007-03-01 at 15:17 +1100, FAST PostgreSQL wrote: > We are happy to provide that. If and when it comes to the final patch being > accepted, we can send a copyright waiver mail which will put our source code > contribution under the BSD license. This approach is not practically workable and is a terrible shame. What would happen if everybody said, "Well, since Fujitsu want to act like that, we won't grant a BSD licence on our material until they grant a BSD licence on theirs." Deadlock. How do we know that you'll ever give that waiver? What would stop you from making contributions right up to the last minute, receiving lots of useful feedback, then at the last minute pulling the patch, once you think its got no problems in it? If you do this, how will any of us fend off *our* corporate lawyers who would like to do the same (probably)? Or did you think the various companies on this list don't have any? I provided my detailed implementation thoughts on the initial proposal. Should I ignore posts from Fujitsu in the future because of this issue? Open source requires trust, not legal brinkmanship. If you're even thinking of submitting patches here, then it should already be clear that the people on this list are better friends to you than people from other companies who provide non-PostgreSQL-based services and products. If you don't believe that, it seems better not to post at all. I'll trust you, and hope that you'll grow to trust others back. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
On Fri, 2 Mar 2007 01:20, Simon Riggs wrote: > On Thu, 2007-03-01 at 15:17 +1100, FAST PostgreSQL wrote: Hi Simon, > > We are happy to provide that. If and when it comes to the final patch > > being accepted, we can send a copyright waiver mail which will put our > > source code contribution under the BSD license. > > This approach is not practically workable and is a terrible shame. I already made a clarification on this subject yesterday. http://archives.postgresql.org/pgsql-patches/2007-02/msg00579.php It is for every patch we submit. Not just the final one. I also sent a contribution statement yesterday regarding one of my patch which is already pending. http://archives.postgresql.org/pgsql-patches/2007-02/msg00581.php > What would happen if everybody said, "Well, since Fujitsu want to act > like that, we won't grant a BSD licence on our material until they grant > a BSD licence on theirs." Deadlock. > > How do we know that you'll ever give that waiver? What would stop you > from making contributions right up to the last minute, receiving lots of > useful feedback, then at the last minute pulling the patch, once you > think its got no problems in it? If you do this, how will any of us fend > off *our* corporate lawyers who would like to do the same (probably)? Or > did you think the various companies on this list don't have any? > > I provided my detailed implementation thoughts on the initial proposal. > Should I ignore posts from Fujitsu in the future because of this issue? > > Open source requires trust, not legal brinkmanship. If you're even > thinking of submitting patches here, then it should already be clear > that the people on this list are better friends to you than people from > other companies who provide non-PostgreSQL-based services and products. > If you don't believe that, it seems better not to post at all. > > I'll trust you, and hope that you'll grow to trust others back. Of course it is. If we didn't trust the community, why would we even want to contribute the source code in the first place.? Rgds, Arul Shaji This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the ordinaryuser of the email address to which it was addressed and may contain copyright and/or legally privileged information.No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive thisemail in error, please return to sender. Thank you. If you do not wish to receive commercial email messages from Fujitsu Australia Software Technology Pty Ltd, please emailunsubscribe@fast.fujitsu.com.au
Hi Gavin,
Thanks for your comments.
I shall set up the ctids list to be stored in memory initially and dump to a
temp file if needed.
Regards,
John Bartlett
-----Original Message-----
From: pgsql-patches-owner@postgresql.org
[mailto:pgsql-patches-owner@postgresql.org] On Behalf Of Gavin Sherry
Sent: Wednesday, 28 February 2007 3:23 PM
To: John Bartlett
Cc: pgsql-hackers@postgresql.org; pgsql-patches@postgresql.org; 'Heikki
Linnakangas'
Subject: Re: [HACKERS] [PATCHES] - WIP Patch Updatable Cursor
On Wed, 28 Feb 2007, John Bartlett wrote:
> Hi,
>
> A list of ctids is stored in the file.
I would have thought these would be stored in memory. If the set got
large, you'd use a temporary file the way other systems which overflow to
disk do?
>
> The file is used to store the ctids during an updatable cursor
transaction.
>
> It is set up as a permanent file as it has a potential lifetime of
> preserving data between crashes of the backend. Temporary files tend to be
> used for data that is defined within a single command. In this case the
file
> needs to exist within a transaction and across backend processes.
It does not. Cursors are implicitly closed when a session is closed. A
backend crash or system restart closes all open sessions.
>
> The file gram.y has been corrected in my version.
>
> The files ctidListStore.c and ctidListStore.h were pasted into the patch
> file, as the diff -N command produced a file of several hundred thousand
> lines.
Edit the file with a text editor. If you know which files should be
excluded (like tags files), use diff --exclude=<pattern>.
Thanks,
Gavin
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 003 693 481. It is confidential to the
ordinaryuser of the email address to which it was addressed and may contain copyright and/or legally privileged
information.No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive
thisemail in error, please return to sender. Thank you.
If you do not wish to receive commercial email messages from Fujitsu Australia Software Technology Pty Ltd, please
emailunsubscribe@fast.fujitsu.com.au
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am playing with this now ... sorry for delay ... - --On Wednesday, February 28, 2007 12:58:04 -0500 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Bruce Momjian <bruce@momjian.us> writes: >> Joshua D. Drake wrote: >>> We should add this to the mailing list signup pages and the welcome >>> pages to the lists. > >> Yep, good idea. Marc? > > For -patches and -hackers, I agree. It seems a bit legalistic and > off-putting for the general lists, though. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster - ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFF7NK+4QvfyHIvDvMRAgmcAJ9SFJPqi1awtlsSPHYMskH0qEXSdACfblCC qODCB1vxRHBNwKj95pIOun4= =Asm5 -----END PGP SIGNATURE-----