SEO

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 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

--
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. +

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

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/


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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



---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

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. +

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

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/


---------------------------(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

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



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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. +

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

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 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


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

>> 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/


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org