Re: [HACKERS] - WIP Patch Updatable Cursor

Поиск
Список
Период
Сортировка
Искать

Re: [HACKERS] - WIP Patch Updatable Cursor

От:
"John Bartlett" <johnb@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=.

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

Re: - WIP Patch Updatable Cursor

От:
"John Bartlett" <johnb@fast.fujitsu.com.au>
Дата:
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 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

От:
"John Bartlett" <johnb@fast.fujitsu.com.au>
Дата:

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

Re: [HACKERS]

От:
Neil Conway <neilc@samurai.com>
Дата:
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

Re: [HACKERS]

От:
Neil Conway <neilc@samurai.com>
Дата:
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

Re: [HACKERS]

От:
<korryd@enterprisedb.com>
Дата:
> 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

Re: WIP Patch - Updateable Cursors

От:
"Simon Riggs" <simon@2ndquadrant.com>
Дата:
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

Re: WIP Patch - Updateable Cursors

От:
"FAST PostgreSQL" <fastpgs@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 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

Re: [HACKERS]

От:
"FAST PostgreSQL" <fastpgs@fast.fujitsu.com.au>
Дата:
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:
>
>     
  • 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.
    • 
>

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

    Re: WIP Patch - Updateable Cursors

    От:
    "FAST PostgreSQL" <fastpgs@fast.fujitsu.com.au>
    Дата:
    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 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

    Re:

    От:
    Bruce Momjian <bruce@momjian.us>
    Дата:
    
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            http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

    Re: [HACKERS]

    От:
    Bruce Momjian <bruce@momjian.us>
    Дата:
    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            http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

    Re: [HACKERS]

    От:
    Bruce Momjian <bruce@momjian.us>
    Дата:
    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            http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

    Re: [HACKERS]

    От:
    Bruce Momjian <bruce@momjian.us>
    Дата:
    
I have added this to the developer's FAQ to clarify the situtation of
posting a patch:

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


---------------------------------------------------------------------------

Tom Lane wrote:
> Bruce Momjian  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            http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

    Re: [HACKERS]

    От:
    Bruce Momjian <bruce@momjian.us>
    Дата:
    Joshua D. Drake wrote:
> Bruce Momjian wrote:
> > I have added this to the developer's FAQ to clarify the situtation of
> > posting a patch:
> > 
> >     
  • 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.
    • 
> 
> 
> 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  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            http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

    Re: [HACKERS]

    От:
    Tom Lane <tgl@sss.pgh.pa.us>
    Дата:
    Bruce Momjian  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

    Re: [HACKERS]

    От:
    Tom Lane <tgl@sss.pgh.pa.us>
    Дата:
    "Joshua D. Drake"  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

    Re: [HACKERS]

    От:
    Tom Lane <tgl@sss.pgh.pa.us>
    Дата:
    "Joshua D. Drake"  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

    Re:

    От:
    Heikki Linnakangas <heikki@enterprisedb.com>
    Дата:
    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

    Re: [HACKERS]

    От:
    "Joshua D. Drake" <jd@commandprompt.com>
    Дата:
    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/

    Re: [HACKERS]

    От:
    "Joshua D. Drake" <jd@commandprompt.com>
    Дата:
    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/

    Re: [HACKERS]

    От:
    "Joshua D. Drake" <jd@commandprompt.com>
    Дата:
    
>> 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/

    Re: [HACKERS]

    От:
    "Joshua D. Drake" <jd@commandprompt.com>
    Дата:
    
> 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/

    Re: [HACKERS]

    От:
    Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
    Дата:
    Tom Lane wrote:
> "Joshua D. Drake"  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

    Re: [HACKERS]

    От:
    "Joshua D. Drake" <jd@commandprompt.com>
    Дата:
    Bruce Momjian wrote:
> I have added this to the developer's FAQ to clarify the situtation of
> posting a patch:
> 
>     
  • 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.
    • 


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

    Re: [HACKERS]

    От:
    "Joshua D. Drake" <jd@commandprompt.com>
    Дата:
    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:
>>
>>     
  • 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.
    • 
>>
> 
> 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/

    Re: [HACKERS]

    От:
    Tom Lane <tgl@sss.pgh.pa.us>
    Дата:
    Bruce Momjian  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

    Re: [HACKERS]

    От:
    "Marc G. Fournier" <scrappy@hub.org>
    Дата:
    -----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  
wrote:

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

    Re: [HACKERS] - WIP Patch Updatable Cursor

    От:
    Gavin Sherry <swm@alcove.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=.

Thanks,

Gavin
    FAQ