date:20160112

Elein  writes:
> The small problem with your version, Joshua, is that the appropriate action 
> is not specified. 

I think at this point we're just trying to agree on a statement as
to what actions are acceptable or not.  After that we can get into
what is the enforcement mechanism; but that's a separable concern
and I believe we're best off keeping it separate for the moment.

(FWIW, I would prefer to see specific remedies mostly left to the
discretion of the enforcers.  There is nothing more broken than
mandatory sentencing rules.  But, really, one thing at a time...)

regards, tom lane

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] WIP: CoC V5

Still trying the Danish "Make Love not Codes" approach (Love being the
plural of the Danish Lov meaning law).

1. The CoC is to provide community guidelines for creating and enforcing a
safe, respectful, productive, and collaborative place for any person who is
willing to contribute in a safe, respectful, productive and collaborative
way.  This CoC is only about interaction via community channels or relating
to community commons.  Your personal lives outside the PostgreSQL community
are your own.

2. Please be respectful of others.  Understand that the community is about
collaboration.  We are here to build and further a software project, so
let's work together.

3. Please try to assume that perceived slights are the result of genuine
miscommunication or different perspective not personal attacks.  Assume
others are being reasonable.

4. Please respect the common work and the need for high quality of code.
Understand that the review process is an opportunity for discussion and
improvement.  Work to further the community and the software, and assume
that others are doing the same.

5. The CoC committee, those they designate may take action as needed to
facilitate or, as necessary, take action to enforce the community
principles and conduct embodied in this CoC.  For affiliated projects, the
maintainers of the project or those they designate may fill the same role
instead.

=

I am going to reiterate my view that a rules approach is not going to
really prevent problems and those who want to harass others can often use
codes of conduct as weapons to do so.  I would rather see something as
general as possible.emphasizing what we want rather than what we want to
avoid.

On Tue, Jan 12, 2016 at 10:37 PM, Joshua D. Drake 
wrote:

> tl;dr;
>
> * Moved #2 to #3 and #3 to #2
> * Added wording for assuming positive intent to #2
>
> PostgreSQL Global Development Group (PGDG) Code of Conduct (CoC):
>
> 1. The CoC is to provide community guidelines for creating and enforcing a
> safe, respectful, productive, and collaborative place for any person who is
> willing to contribute in a safe, respectful, productive and collaborative
> way.
>
> 2. A safe, respectful, productive and collaborative environment is free of
> personal attacks and disparaging remarks of any kind.
>
> 3. The CoC is not about being offended. One should always assume good
> intentions. As with any diverse community, anyone can get offended at
> anything.
>
> 4. Any sustained disruption of the collaborative space (mailing lists, IRC
> etc..) or other PostgreSQL events shall be construed as a violation of the
> CoC and appropriate action will be taken by the CoC committee.
>
> 5. The CoC is only about interaction with the PostgreSQL community. Your
> private and public lives outside of the PostgreSQL community are your own.
>
>
>
> --
> Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
> PostgreSQL Centered full stack support, consulting and development.
> Announcing "I'm offended" is basically telling the world you can't
> control your own emotions, so everyone else should do it for you.
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

-- 
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor
lock-in.
http://www.efficito.com/learn_more

Re: [GENERAL] WIP: CoC V5


On 01/12/2016 07:10 PM, Tom Lane wrote:

Kevin Grittner  writes:

I'm not the greatest word-smith, but I'll attempt to rework Josh's
draft to something that seems more "natural" to me.


Minor (or not?) comment:


* To maintain a safe, respectful, productive and collaborative
environment all participants must ensure that their language and
actions are free of personal attacks and disparaging remarks of any
kind.


The "disparaging remarks" part of this could easily be taken to forbid
technical criticism of any sort, eg "this patch is bad because X,Y, and
Z", even when X,Y, and Z are perfectly neutral technical points.  "Of any
kind" doesn't improve that either.  I'm on board with the "personal
attacks" part.  Maybe "disparaging personal remarks" would be better?


Hrm, I see your point but the definition of disparaging is:

expressing the opinion that something is of little worth; derogatory.

I guess if we got into a VI vs Emacs argument the CoC could apply but 
wouldn't that also be a good thing?


JD



regards, tom lane




--
Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Unable to build python extension with PGXS

2016-01-12 Thread Jim Nasby


Attempting to build a python extension, I'm getting:

Undefined symbols for architecture x86_64:
  "_PyErr_Clear", referenced from:
  _PLyNdarray_FromDatum in pg_ndarray.o
  _PLyObject_To_ndarray in pg_ndarray.o
  "_PyImport_ImportModule", referenced from:
  _PLyNdarray_FromDatum in pg_ndarray.o
  _PLyObject_To_ndarray in pg_ndarray.o
  "_PyObject_CallFunction", referenced from:
  _PLyNdarray_FromDatum in pg_ndarray.o
  _PLyObject_To_ndarray in pg_ndarray.o
  "_PyObject_GetAttrString", referenced from:
  _PLyNdarray_FromDatum in pg_ndarray.o
  _PLyObject_To_ndarray in pg_ndarray.o
  "_PyString_AsString", referenced from:
  _PLyObject_To_ndarray in pg_ndarray.o
  "_PyString_FromStringAndSize", referenced from:
  _PLyNdarray_FromDatum in pg_ndarray.o
  "_PyString_Size", referenced from:
  _PLyObject_To_ndarray in pg_ndarray.o
ld: symbol(s) not found for architecture x86_64

I've included $(python_includespec) in my Makefile:

override CPPFLAGS := $(python_includespec) $(CPPFLAGS)

Is there some other magic I need? Do I need to switch to using
MODULE_big or something?
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] WIP: CoC V5

Kevin Grittner  writes:
> I'm not the greatest word-smith, but I'll attempt to rework Josh's
> draft to something that seems more "natural" to me.

Minor (or not?) comment:

> * To maintain a safe, respectful, productive and collaborative
> environment all participants must ensure that their language and
> actions are free of personal attacks and disparaging remarks of any
> kind.

The "disparaging remarks" part of this could easily be taken to forbid
technical criticism of any sort, eg "this patch is bad because X,Y, and
Z", even when X,Y, and Z are perfectly neutral technical points.  "Of any
kind" doesn't improve that either.  I'm on board with the "personal
attacks" part.  Maybe "disparaging personal remarks" would be better?

regards, tom lane

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] WIP: CoC V5


On 01/12/2016 07:04 PM, Tom Lane wrote:

"Joshua D. Drake"  writes:

On 01/12/2016 02:43 PM, Kevin Grittner wrote:

To me, this reads more like the document itself.  I hope I have
done justice to Josh's points as well as Tom's, although I would
bet there are a number of people on the list that can improve on my
effort here.



I read your whole document. It is not badly written and I would agree it
does read a bit more like a lot of the CoCs out there. My critique would
be that it adds words for the sake of adding words. The more words the
more ambiguity and the more nits to pick.



As we have all appeared to coalesce around v5, I would suggest that we
stick with it or gently modify v5 up to the point that it is something
that sticks.


Um, you may have coalesced around v5, but I'm not sure there's consensus
there.  I agree with Kevin that his version looks a lot more like a real
CoC.  His is surely still amenable to some editing, but there are also
things in your version that we can do without.  Particularly the "not
about being offended" line.  That's pretty defensive and unwelcoming,
IMO, and that isn't the image we want to project here.


Even with the V5? There is a pretty good point there IMO. It is very 
easy to get offended over really stupid things (including just standard 
miscommunication).


That said, I actually don't have a problem taking that point out and 
making that V6.


JD



regards, tom lane




--
Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] WIP: CoC V5


On 01/12/2016 06:41 PM, Elein wrote:

The small problem with your version, Joshua, is that the appropriate action is 
not specified.

Sorry to jump in in the middle. I have not read the comments fully.



It is all good Elein. The lack of appropriate action is purposeful. The 
idea is that we decide on a CoC. Then we decide on the next step. Under 
current structure that would fall to core. I am of the opinion that the 
"action" that the committee decides would be with exception to -core, 
with -core being the final (board of directors vote). However, I think 
that can all be solved after wording is decided.


JD

--
Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] WIP: CoC V5


On 01/12/2016 06:55 PM, Tom Lane wrote:

Elein  writes:

The small problem with your version, Joshua, is that the appropriate action is 
not specified.


I think at this point we're just trying to agree on a statement as
to what actions are acceptable or not.  After that we can get into
what is the enforcement mechanism; but that's a separable concern
and I believe we're best off keeping it separate for the moment.

(FWIW, I would prefer to see specific remedies mostly left to the
discretion of the enforcers.  There is nothing more broken than
mandatory sentencing rules.  But, really, one thing at a time...)\


Exactly. +1



regards, tom lane




--
Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Data Packaging/Data Unpacking

2016-01-12 Thread oleg yusim

Greetings,

I have matching couple of security requirements, speaking about preserving
data confidentiality and integrity in PostgreSQL DB during packaging for
transmission / unpacking from transmission.

Important: let's assume data at rest is encrypted using EFS and data at
transit is encrypted using ciphers, provided by OpenSSL.

So, with that in mind, please, help me to understand movement and location
of the data between the moment when it is pulled from file system and
encrypted as network package going through the SSL tunnel.

And reversing it - between the moment network package arrived through the
SSL tunnel is decrypted and the moment its content is placed into the file
system.



For those interested, here are requirements themselves, quoted:

1) The DBMS must maintain the confidentiality and integrity of information
during preparation for transmission.

Information can be either unintentionally or maliciously disclosed or
modified during preparation for transmission, including, for example,
during aggregation, at protocol transformation points, and during
packing/unpacking. These unauthorized disclosures or modifications
compromise the confidentiality or integrity of the information.

Use of this requirement will be limited to situations where the data owner
has a strict requirement for ensuring data integrity and confidentiality is
maintained at every step of the data transfer and handling process.

When transmitting data, the DBMS, associated applications, and
infrastructure must leverage transmission protection mechanisms.

2) The DBMS must maintain the confidentiality and integrity of information
during reception.

Information can be either unintentionally or maliciously disclosed or
modified during reception, including, for example, during aggregation, at
protocol transformation points, and during packing/unpacking. These
unauthorized disclosures or modifications compromise the confidentiality or
integrity of the information.

This requirement applies only to those applications that are either
distributed or can allow access to data non-locally. Use of this
requirement will be limited to situations where the data owner has a strict
requirement for ensuring data integrity and confidentiality is maintained
at every step of the data transfer and handling process.

When receiving data, the DBMS, associated applications, and infrastructure
must leverage protection mechanisms.


Thanks,

Oleg

Re: [GENERAL] Code of Conduct: Is it time?

On Tue, Jan 12, 2016 at 3:21 PM, James Keener  wrote:

> This line has already been substantially changes. Can we keep discussion
> of the language of the WIP in the thread meant for it? This way people
> don't waste time discussing language which no longer exists.
>

I think the question though is relevant to a more general question of codes
of conduct.

Here is where I see the danger.

This is a global project.  It is going to involve people with wide
perspectives on controversial and sensitive issues.  It is not
inconceivable that we will include groups on the email lists who see the
mere presence of eachother as a personal attack.  Coming up with examples
would probably be inappropriate but PostgreSQL is widely used and so that
may happen.

In LedgerSMB we have had civilians on the project in countries that were
threatening to go to war with eachother.  But at least those weren't
culture war issues so we more or less just worked through the situation.

A second problem is that my experience is that folks who are going to push
people's buttons are going to be careful to do so in order to ensure the
community doesn't see it.  To be frank, bullies usually have a level of
political sophistication that their victims lack and I don't see how a CoC
fixes that.  (If it is just to say "yes we have one" then my experience is
also such that I worry about those people who worry about that.)

One of the nice things about the Ubuntu Code of Conduct is that it focuses
primarily on the positive.  It is long, perhaps overly verbose, but it does
focus on what the community wants rather than what the community wants to
avoid.

It is easy to say "don't do these things."  But it is perhaps better to say
"these are the values our community lives by.  Please respect them."

>
> Jim
>
> On January 12, 2016 9:17:55 AM EST, Neil Tiffin 
> wrote:
>>
>>
>>  On Jan 12, 2016, at 7:50 AM, Vick Khera  wrote:
>>>
>>>  On Mon, Jan 11, 2016 at 6:55 PM, Steve Litt  
>>> wrote:
>>>
  All because somebody just *had* to personally insult someone else,
  repeatedly, and nobody thought that was a bad thing, and when the
  recipient finally objected, the objection was chalked up to him or her
  valuing his/her victimhood.

>>>
>>>  +1
>>>
>>>  I was thinking along the same lines when I saw JD's original list
>>>  containing that "victimhood" line. I think that one line pretty much
>>>  eviscerates the entire purpose of having the CoC.
>>>
>>>
>> I don’t remember the “victimhood”
>> line, but it is important to make sure people understand that the problem 
>> manifests itself both by being to sensitive by the complainer and not being 
>> sensitive enough by the group. I do believe that in any document it needs to 
>> be stated that everyone is expected to be tolerant of others.  A free 
>> society cannot exist without some level of tolerance.
>>
>> Neil
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>

-- 
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor
lock-in.
http://www.efficito.com/learn_more

Re: [GENERAL] Moving a large DB (> 500GB) to another DB with different locale

2016-01-12 Thread John McKown

On Tue, Jan 12, 2016 at 4:09 PM, Andreas Joseph Krogh 
wrote:

> På tirsdag 12. januar 2016 kl. 22:56:56, skrev John R Pierce <
> pie...@hogranch.com>:
>
> On 1/12/2016 1:20 PM, Andreas Joseph Krogh wrote:
> > I'm moving a > 500GB DB to another server which is initdb'ed with a
> > different locale (nb_NO.UTF-8 to get correct collation when ORDER BY).
> > Is there another option than pg_dump/restore for doing this?
>
> nope, because the text data has to be converted to the new encoding,
> indexes rebuilt since the collation order is different, etc.
>
>
> I was pretty sure there wasn't, but had to ask before imposing downtime on
> our customers.
>
> Thanks.
>
> --
> *Andreas Joseph Krogh*
> CTO / Partner - Visena AS
> Mobile: +47 909 56 963
> andr...@visena.com
> www.visena.com
> 
>
>

I install, maintain, and use PostgreSQL on Fedora Linux. But only as a
type of "power" user. I'm not a DBA. Nor do I have good knowledge of
PostgreSQL internals. What I gather you are considering is something like:

server1: pg_dump one or more data bases to a file on server1 (or on an NFS
/ CIFS shared NAS box of some sort)
server1: transfer that file to server2 if necessary (i.e. if the file
dumped on server1 is not readable directly on server2.
server2: pg_restore the data from the file.

What I am wondering is this: Is there some way to make the PostgreSQL
instance on server2 be accessable, say via FDW, to PostgreSQL on server1?
Or may vice versa.
ref: http://www.postgresql.org/docs/current/static/postgres-fdw.html
if so, would it be possible to do something like:

on server1:

CREATE EXTENSION posgres_fdw;
CREATE SERVER server2
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS(host 'a.b.c.d', port '5432', db_name 'bubba')
;
CREATE USER MAPPING FOR 
SERVER server2
OPTIONS(user 'remote_user', password 'password')
;
CREATE FOREIGN TABLE server2_sometable (
   -- duplicate definition of "sometable" on server2
) SERVER server2 OPTIONS(schema_name 'PUBLIC', table_name 'sometable')
;
INSERT INTO server2_sometable (COL1, COL2, COL3, ...) SELECT COL1, COL2,
COL3, ... FROM sometable;

This is most likely a stupid thought. And I don't know if it would address
the locale and collation issue or not. If nothing else, someone will
explain (hopefully kindly) why this is a bad idea. Such as performance or
some such thing.

An auxiliary thought, if the communications speed between server1 & server2
is "poor", would be to have two copies of PostgreSQL running on server1.
The second Postgres would write to a filesystem on an SSD connected to
Server1, either via SATA, eSATA, or maybe USB. I would hope that this would
be faster than using a 1Gig (or ever 10 Gig) IP connection. Once the copy
is complete, stop the second Postgres instance, unmount the filesystem,
move the SSD to "server2" hardware platform.

Just some wacky thoughts. They are right at home in my head.

-- 
Werner Heisenberg is driving down the autobahn. A police officer pulls
him over. The officer says, "Excuse me, sir, do you know how fast you
were going?"
"No," replies Dr. Heisenberg, "but I know where I am."

Computer Science is the only discipline in which we view adding a new wing
to a building as being maintenance -- Jim Horning

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

He's about as useful as a wax frying pan.

Maranatha! <><
John McKown

Re: [GENERAL] Moving a large DB (> 500GB) to another DB with different locale

2016-01-12 Thread Vick Khera

On Tue, Jan 12, 2016 at 4:20 PM, Andreas Joseph Krogh 
wrote:

> I'm moving a > 500GB DB to another server which is initdb'ed with a
> different locale (nb_NO.UTF-8 to get correct collation when ORDER BY).
> Is there another option than pg_dump/restore for doing this?
>

I recently used slony to move data stored in an SQL_ASCII db to one that
was strict UTF-8. I wrote up a program that would fix any invalid byte
sequences in the original db first. It went very well, and we had very
minimal downtime.

It seems to me you could use slony to accomplish your goal as well of just
copying the data into a new DB with the different collation setting. Once
done, just stop your application for a minute or two to switch the DB it
uses, and drop the slony replication. This process will work if you can
assure that the dump/restore would have worked too. That is, there are no
invalid data.

Re: [GENERAL] WIP: CoC V5

2016-01-12 Thread Bill Moran

On Tue, 12 Jan 2016 22:10:43 -0500
Tom Lane  wrote:

> Kevin Grittner  writes:
> > I'm not the greatest word-smith, but I'll attempt to rework Josh's
> > draft to something that seems more "natural" to me.
> 
> Minor (or not?) comment:
> 
> > * To maintain a safe, respectful, productive and collaborative
> > environment all participants must ensure that their language and
> > actions are free of personal attacks and disparaging remarks of any
> > kind.
> 
> The "disparaging remarks" part of this could easily be taken to forbid
> technical criticism of any sort, eg "this patch is bad because X,Y, and
> Z", even when X,Y, and Z are perfectly neutral technical points.  "Of any
> kind" doesn't improve that either.  I'm on board with the "personal
> attacks" part.  Maybe "disparaging personal remarks" would be better?

When I used to write fiction, I met regularly with a writing group.
We had a very explicit rule: criticize the manuscript, NOT the author.

I feel this applies ... and possibly could be worded to that effect,
"Critical remarks regarding patches and/or technical work are
necessary to ensure a quality product; however, critical remarks
directed at individuals are not constructive and therefore not
acceptable." or something ...

-- 
Bill Moran


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] WIP: CoC V5

"Joshua D. Drake"  writes:
> On 01/12/2016 02:43 PM, Kevin Grittner wrote:
>> To me, this reads more like the document itself.  I hope I have
>> done justice to Josh's points as well as Tom's, although I would
>> bet there are a number of people on the list that can improve on my
>> effort here.

> I read your whole document. It is not badly written and I would agree it 
> does read a bit more like a lot of the CoCs out there. My critique would 
> be that it adds words for the sake of adding words. The more words the 
> more ambiguity and the more nits to pick.

> As we have all appeared to coalesce around v5, I would suggest that we 
> stick with it or gently modify v5 up to the point that it is something 
> that sticks.

Um, you may have coalesced around v5, but I'm not sure there's consensus
there.  I agree with Kevin that his version looks a lot more like a real
CoC.  His is surely still amenable to some editing, but there are also
things in your version that we can do without.  Particularly the "not
about being offended" line.  That's pretty defensive and unwelcoming,
IMO, and that isn't the image we want to project here.

regards, tom lane

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Code of Conduct: Is it time?

On Tue, Jan 12, 2016 at 9:16 AM, Regina Obe  wrote:

> Chris,
>
>
>
> The first part up to (I is fine), but part II and below reads more like a
> Core Contributor riot act you force all the main contributor's to read
> before you bless them with water and give them keys to commit stuff to your
> code base.
>

I am not sold on the specifics of what is covered.  But it is worth noting
that responsibility can include a lot of other stuff too, not just keys for
committing.  Thing about side projects and the like.  That's why I included
it.   It could easily be replaced by something else (perhaps addressing
what you are discussing below).

>
>
> Like our committer guidelines --
> https://trac.osgeo.org/postgis/wiki/DevWikiComitGuidelines
>
>
>
> For a Coc – I think it should be light, but make it clear that we do not
> tolerate strangers coming into our group and demanding us to accept their
> code, cause we want to be welcoming and show we have at least 15% of code
> contributions from women.
>

One of the dangers of a CoC is that there are many potential issues which
may or may not become real problems.  I think if we try to be clear on all
of them, then we risk creating codes instead of a general expectation of
what we do expect.

So my question would be how do you turn this around and frame it as a
positive value and direction?

I assume respecting the commons is insufficient.  Maybe a brief note about
the fact that this is critical software and we have to maintain very high
standards of code?

>
>
> Thanks,
>
> Regina
>
>
>
> *From:* Chris Travers [mailto:chris.trav...@gmail.com]
> *Sent:* Tuesday, January 12, 2016 3:05 AM
> *To:* Regina Obe 
> *Cc:* Buford Tannen ; Joshua D. Drake <
> j...@commandprompt.com>; Brian Dunavant ; Scott Mead <
> sco...@openscg.com>; Adrian Klaver ; Gavin
> Flower ; PostgreSQL General <
> pgsql-general@postgresql.org>
> *Subject:* Re: [GENERAL] Code of Conduct: Is it time?
>
>
>
> A couple thoughts rather late to the discussion from a more international
> perspective.
>
> I remember a lecture I saw by a comparative law professor (the lecture was
> about why many Danes are unhappy with the EU pressures on their tradition
> of law and the general lack of subsidiarity in the EU) who described the
> difference between the Danish and the American system as "Make love not
> codes."  The pun here is that "love" is the plural form of the word for law
> in Danish.  Scandinavian laws tend to be short and rely on human judgment
> by judges rather than precedent and complexity like the American system or
> the equivalents in the civil law/Continental systems.  Without bringing up
> those political issues, I think the approach to decentralization is a good
> one for many projects.
>
> I think this might give us a happy middle ground.  Something very basic,
> very brief which sets forth principles of the community but doesn't amount
> to real rule-making and respects the general decentralized nature of the
> project.
>
> We have a highly decentralized community and an approach needs to reflect
> that.  I think therefore it is important  to keep things brief and vague on
> details but specific in shared principles.
>
> I would also be concerned that someone who is overly worried about not
> having a code of conduct might be interested in lawyering about it.
> Another concern may be "is there a place for me in the project?" and I
> think that can be answered differently.
>
> So with these thoughts, how about something more like:
>
> I:  Be Respectful and Collaborative
>
> We are a global project and expect that people from a wide variety of
> backgrounds and viewpoints will work together.  Personal attacks are not
> appreciated, and the same goes for attacks on the basis of nationality,
> culture, or other factors of inter- and intra-cultural identity.
>
> At the same time, understand that people often cannot see across different
> perspectives and may unintentionally say things that cause offense.  It is
> also a matter of respect and collaboration not to make these into issues.
>
>
>
> II:  Be Responsible
>
> If you have taken on responsibility in a community project and are unable
> to continue, please step down gracefully and help facilitate others taking
> your place.  This includes being around to facilitate knowledge transfer
> and much more.
>
>
>
> III:  Respect the Commons
>
> We are all here to build an outstanding open source project or set of such
> projects.Act in a way which furthers the commons generally, as a
> custodian of what we have inherited from the efforts of others, and
> borrowed from the future.
>
>
>
> In the event of serious problems, the core committee or those they
> designate, or the maintainers of other affiliated projects (in their
> domains) may be called upon to mediate or even address issues (particularly
> in the case of serious

Re: [GENERAL] PostgreSQL upgrade 9.3.4 -> 9.3.10

2016-01-12 Thread Francisco Olarte

Hello:

On Tue, Jan 12, 2016 at 10:28 AM, Dev Kumkar  wrote:
> I want to upgrade my database from version 9.3.4 to 9.3.10.
>
> For this task, do I need to upgrade database using pg_upgrade utility?
> http://www.postgresql.org/docs/9.3/static/pgupgrade.html

No, that is a minor release. Minor version upgrades are normally just
install new vesion & restart. In fact we usually install the new
version over the old one and just restart the server ( but YMMV,
specially if you use one of those operating systems which do not let
you delete open files ).

Minor (9.3.4->9.3.10) version normally preserve on disk formats, so
nothing needs to be done.

Mayor ( 9.3.4 -> 9.4.x )  do not, and they normally need either a dump
& restore or a pg_upgrade ( which works like an optimized dump &
restore ).

In any case, read the release notes ( 9.3 docs, at
end,http://www.postgresql.org/docs/9.3/static/release.html ) for
versions 9.3.5-10, specially the headers, any special instructions
should be contained here, when you read 'A dump/restore is not
required for those running 9.3.X.' it meand you can just install and
restart.

> From the details it looks like for minor version upgrade pg_upgrade utility
> is not required.
> "pg_upgrade (formerly called pg_migrator) allows data stored in PostgreSQL
> data files to be upgraded to a later PostgreSQL major version without the
> data dump/reload typically required for major version upgrades, e.g. from
> 8.4.7 to the current major release of PostgreSQL. It is not required for
> minor version upgrades, e.g. from 9.0.1 to 9.0.4."
>
> Can someone please provide more details here and also what steps needs to be
> done to upgrade to 9.3.10 level?

When postgres changes on-disk formats it bumps the major version.
Normally these used to mean you needed to dump & restore the database,
( Using the NEWER dump/restore utilities, as 9.4 dump/restore know how
to deal with a 9.3 DB, but 9.3 D/R do not even know wether a 9.4
version exists )

pg_upgrade was developed because the on-disk format changes are
tipically minor, and a special program could be made to transform the
data from a version to a later one faster than dumping & restoring,
but is more or less equivalent to doing that. As minor version
upgrades do not need dump/restore, they do not need pg_upgrade either.

Francisco Olarte.

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] PostgreSQL upgrade 9.3.4 -> 9.3.10

2016-01-12 Thread John R Pierce


On 1/12/2016 1:28 AM, Dev Kumkar wrote:


I want to upgrade my database from version 9.3.4 to 9.3.10.

For this task, do I need to upgrade database using pg_upgrade utility?
http://www.postgresql.org/docs/9.3/static/pgupgrade.html


From the details it looks like for minor version upgrade pg_upgrade 
utility is not required.
"pg_upgrade (formerly called pg_migrator) allows data stored in 
PostgreSQL data files to be upgraded to a later PostgreSQL major 
version without the data dump/reload typically required for major 
version upgrades, e.g. from 8.4.7 to the current major release of 
PostgreSQL. It is not required for minor version upgrades, e.g. from 
9.0.1 to 9.0.4."


Can someone please provide more details here and also what steps needs 
to be done to upgrade to 9.3.10 level?




you can do an inplace upgrade of the software, as others said, 
pg_upgrade is for upgrading from 9.X to 9.Y where Y>X


however, its always a good idea to check the release notes of the 
version you're upgrading to, and seeing if there are any special issues, 
for instance, sometimes there's a potential bug in an obscure feature in 
said A.B.C version, and upgrading to A.B.D might require a reindex or 
something. http://www.postgresql.org/docs/current/static/release-9-3-10.html


I don't see anything specifically for 9.3.4 to 9.3.10 but read it for 
yourself, following the links to the applicable intermediate release notes.

.

--
john r pierce, recycling bits in santa cruz

Re: [GENERAL] Code of Conduct: Is it time?

A couple thoughts rather late to the discussion from a more international
perspective.

I remember a lecture I saw by a comparative law professor (the lecture was
about why many Danes are unhappy with the EU pressures on their tradition
of law and the general lack of subsidiarity in the EU) who described the
difference between the Danish and the American system as "Make love not
codes."  The pun here is that "love" is the plural form of the word for law
in Danish.  Scandinavian laws tend to be short and rely on human judgment
by judges rather than precedent and complexity like the American system or
the equivalents in the civil law/Continental systems.  Without bringing up
those political issues, I think the approach to decentralization is a good
one for many projects.

I think this might give us a happy middle ground.  Something very basic,
very brief which sets forth principles of the community but doesn't amount
to real rule-making and respects the general decentralized nature of the
project.

We have a highly decentralized community and an approach needs to reflect
that.  I think therefore it is important  to keep things brief and vague on
details but specific in shared principles.

I would also be concerned that someone who is overly worried about not
having a code of conduct might be interested in lawyering about it.
Another concern may be "is there a place for me in the project?" and I
think that can be answered differently.

So with these thoughts, how about something more like:

I:  Be Respectful and Collaborative

We are a global project and expect that people from a wide variety of
backgrounds and viewpoints will work together.  Personal attacks are not
appreciated, and the same goes for attacks on the basis of nationality,
culture, or other factors of inter- and intra-cultural identity.

At the same time, understand that people often cannot see across different
perspectives and may unintentionally say things that cause offense.  It is
also a matter of respect and collaboration not to make these into issues.

II:  Be Responsible

If you have taken on responsibility in a community project and are unable
to continue, please step down gracefully and help facilitate others taking
your place.  This includes being around to facilitate knowledge transfer
and much more.

III:  Respect the Commons

We are all here to build an outstanding open source project or set of such
projects.Act in a way which furthers the commons generally, as a
custodian of what we have inherited from the efforts of others, and
borrowed from the future.

In the event of serious problems, the core committee or those they
designate, or the maintainers of other affiliated projects (in their
domains) may be called upon to mediate or even address issues (particularly
in the case of serious and repeated problems).  However, the community is
expected to operate in a way which prevents this from becoming necessary by
adhering to the principles above even in the process of addressing
disputes..

On Mon, Jan 11, 2016 at 11:13 PM, Regina Obe  wrote:

>
> Regina Obe wrote:
> >
> > If we do write a CoC, can we give it a different acronym.
>
> > Notwithstanding the most regrettable childhood trauma, this request is
> exactly the kind of ridiculousness that the Political Correctness nonsense
> associated with CoCs that we should be worried about in the aftermath of
> proposed adoption.
>
> > Complaining that the acronym "CoC" is anything remotely like the thing
> the work "cock" means is, well, cockamamie
>
> > It's like someone becoming upset over the work "niggardly" as a racist
> epithet. In fact that word and the one you are thinking of are completely
> unrelated: entirely different etymology. Nothing in common except, on the
> one hand, as you imagine the acronym might be pronounced, and on the other
> because there are six similar letters.
>
> Exactly.  That's why I added that section:
>
>
> ---
>
> USE OF TRIGGER TERMS
>
> We have long standing terms like Master/Slave that may trigger some past
> trauma for some people.
> While we do consider people's feelings, we weigh that against the effort
> of changing long understood terminology and the psychological trauma
> such changes would cause for the large majority of people who are not as
> sensitive to the usage.
> As such we entertain change requests for naming of new features more than
> we do of renaming old features.
>
> -
>
> First of all you have no proof whether I was raped or not, so you don't
> know if I'm just playing the "Poor woman was raped, give her a break" card
> or if my sad luck story is genuine.
> In the end it's irrelevant, because as Josh apologetically explained to
> me  -

Re: [GENERAL] Code of Conduct: Is it time?

Chris,

The first part up to (I is fine), but part II and below reads more like a Core 
Contributor riot act you force all the main contributor's to read before you 
bless them with water and give them keys to commit stuff to your code base.

Like our committer guidelines -- 
https://trac.osgeo.org/postgis/wiki/DevWikiComitGuidelines

For a Coc – I think it should be light, but make it clear that we do not 
tolerate strangers coming into our group and demanding us to accept their code, 
cause we want to be welcoming and show we have at least 15% of code 
contributions from women.

Thanks,

Regina

From: Chris Travers [mailto:chris.trav...@gmail.com] 
Sent: Tuesday, January 12, 2016 3:05 AM
To: Regina Obe 
Cc: Buford Tannen ; Joshua D. Drake 
; Brian Dunavant ; Scott Mead 
; Adrian Klaver ; Gavin Flower 
; PostgreSQL General 

Subject: Re: [GENERAL] Code of Conduct: Is it time?

A couple thoughts rather late to the discussion from a more international 
perspective.

I remember a lecture I saw by a comparative law professor (the lecture was 
about why many Danes are unhappy with the EU pressures on their tradition of 
law and the general lack of subsidiarity in the EU) who described the 
difference between the Danish and the American system as "Make love not codes." 
 The pun here is that "love" is the plural form of the word for law in Danish.  
Scandinavian laws tend to be short and rely on human judgment by judges rather 
than precedent and complexity like the American system or the equivalents in 
the civil law/Continental systems.  Without bringing up those political issues, 
I think the approach to decentralization is a good one for many projects.

I think this might give us a happy middle ground.  Something very basic, very 
brief which sets forth principles of the community but doesn't amount to real 
rule-making and respects the general decentralized nature of the project.

We have a highly decentralized community and an approach needs to reflect that. 
 I think therefore it is important  to keep things brief and vague on details 
but specific in shared principles.

I would also be concerned that someone who is overly worried about not having a 
code of conduct might be interested in lawyering about it.  Another concern may 
be "is there a place for me in the project?" and I think that can be answered 
differently.

So with these thoughts, how about something more like:

I:  Be Respectful and Collaborative

We are a global project and expect that people from a wide variety of 
backgrounds and viewpoints will work together.  Personal attacks are not 
appreciated, and the same goes for attacks on the basis of nationality, 
culture, or other factors of inter- and intra-cultural identity.

At the same time, understand that people often cannot see across different 
perspectives and may unintentionally say things that cause offense.  It is also 
a matter of respect and collaboration not to make these into issues.

II:  Be Responsible

If you have taken on responsibility in a community project and are unable to 
continue, please step down gracefully and help facilitate others taking your 
place.  This includes being around to facilitate knowledge transfer and much 
more.

III:  Respect the Commons

We are all here to build an outstanding open source project or set of such 
projects.Act in a way which furthers the commons generally, as a custodian 
of what we have inherited from the efforts of others, and borrowed from the 
future. 

In the event of serious problems, the core committee or those they designate, 
or the maintainers of other affiliated projects (in their domains) may be 
called upon to mediate or even address issues (particularly in the case of 
serious and repeated problems).  However, the community is expected to operate 
in a way which prevents this from becoming necessary by adhering to the 
principles above even in the process of addressing disputes..

On Mon, Jan 11, 2016 at 11:13 PM, Regina Obe  > wrote:

Regina Obe wrote:
>
> If we do write a CoC, can we give it a different acronym.

> Notwithstanding the most regrettable childhood trauma, this request is 
> exactly the kind of ridiculousness that the Political Correctness nonsense 
> associated with CoCs that we should be worried about in the aftermath of 
> proposed adoption.

> Complaining that the acronym "CoC" is anything remotely like the thing the 
> work "cock" means is, well, cockamamie

> It's like someone becoming upset over the work "niggardly" as a racist 
> epithet. In fact that word and the one you are thinking of are completely 
> unrelated: entirely different etymology. Nothing in common except, on the one 
> hand, as you imagine the acronym might be pronounced, and

Re: [GENERAL] Giving error for function

2016-01-12 Thread Charles Clavadetscher

Hello

> -Original Message-
> From: pgsql-general-ow...@postgresql.org 
> [mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Sachin Srivastava
> Sent: Dienstag, 12. Januar 2016 08:40
> To: pgsql-general@postgresql.org >> PG-General Mailing List 
> 
> Subject: [GENERAL] Giving error for function
> 
> Hi,
> 
> I am getting the below error while I am running the below function 
> "add_po_doc_hist", for "c_company" cursor, please
> suggest what is wrong with code.
> 
> 
> 
> ERROR:  relation "c_company" does not exist

Probably you need to schema qualify the table name.

> 
> CONTEXT:  compilation of PL/pgSQL function "add_po_doc_hist" near line 11
> 
> ** Error **
> 
> 
> 
> ERROR: relation "c_company" does not exist
> 
> SQL state: 42P01
> 
> Context: compilation of PL/pgSQL function "add_po_doc_hist" near line 11
> 
> 
> 
> 
> 
>  
> ---
> --
> 
> -- Function: add_po_doc_hist(bigint)
> 
> 
> 
> -- DROP FUNCTION add_po_doc_hist(bigint);
> 
> 
> 
> CREATE OR REPLACE FUNCTION add_po_doc_hist(subscriberid bigint)
> 
>   RETURNS void AS
> 
> $BODY$
> 
> DECLARE
> 
> 
> 
> --Select All Companies for the subscriber entered
> 
> c_company CURSOR FOR
> 
> SELECT company_id
> 
> from PSM_COMPANY_PROFILE
> 
> where is_BUYER = 1
> 
>   and subscriber_id=subscriberID;
> 
> 
> 
> v_company c_company%ROWTYPE;
> 
> counter bigint :=1;
> 
> 
> 
> BEGIN
> 
> 
> 
> open c_company;
> 
> loop
> 
> fetch c_company into v_company;
> 
> IF NOT FOUND THEN EXIT; END IF; -- apply on 
> c_company
> 
> 
> 
> --insert in PDOC_CHANGE_HIST_HEADER
> 
> insert into PDOC_CHANGE_HIST_HEADER
> 
> (SUBSCRIBER_ID, COMPANY_ID, 
> DOCUMENT_ID,
> 
>   DESCRIPTION, COMMENTS,
> 
>   CREATION_DATE, CREATION_USER, UPDATE_DATE, UPDATE_USER )
> 
> values(subscriberID, v_company.company_id, 
> 15197,
> 
> 'Buyer PO History', '',
> 
> LOCALTIMESTAMP, 'AppAdmin', LOCALTIMESTAMP, 'AppAdmin' );
> 
> 
> 
> --First Row insert in PDOC_CHANGE_HIST_DETAIL
> 
> insert into PDOC_CHANGE_HIST_DETAIL
> 
> (SUBSCRIBER_ID, COMPANY_ID, 
> DOCUMENT_ID, ROW_NUMBER,
> 
>   TABLE_NAME, TABLE_COLUMN_NAME, FIELD_ID,
> 
>   CREATION_DATE, CREATION_USER, UPDATE_DATE, UPDATE_USER )
> 
> values(subscriberID, v_company.company_id, 
> 15197, 1,
> 
> 'PPO_MASTER_HEADER', 'SUPPLIER_CONTACT_ID', 15385,
> 
> LOCALTIMESTAMP, 'AppAdmin', LOCALTIMESTAMP, 'AppAdmin' );
> 
> 
> 
> --Second Row insert in PDOC_CHANGE_HIST_DETAIL
> 
> insert into PDOC_CHANGE_HIST_DETAIL
> 
> (SUBSCRIBER_ID, COMPANY_ID, 
> DOCUMENT_ID, ROW_NUMBER,
> 
>   TABLE_NAME, TABLE_COLUMN_NAME, FIELD_ID,
> 
>   CREATION_DATE, CREATION_USER, UPDATE_DATE, UPDATE_USER )
> 
> values(subscriberID, v_company.company_id, 
> 15197, 2,
> 
> 'PPO_MASTER_HEADER', 'STATUS', 15192,
> 
> LOCALTIMESTAMP, 'AppAdmin', LOCALTIMESTAMP, 'AppAdmin' );
> 
> 
> 
>--Third Row insert in PDOC_CHANGE_HIST_DETAIL
> 
> insert into PDOC_CHANGE_HIST_DETAIL
> 
> (SUBSCRIBER_ID, COMPANY_ID, 
> DOCUMENT_ID, ROW_NUMBER,
> 
>   TABLE_NAME, TABLE_COLUMN_NAME, FIELD_ID,
> 
>   CREATION_DATE, CREATION_USER, UPDATE_DATE, UPDATE_USER )
> 
> values(subscriberID, v_company.company_id, 
> 15197, 3,
> 
> 'PPO_MASTER_HEADER', 'APPROVAL_PERSON_ID', 20883,
> 
> LOCALTIMESTAMP, 'AppAdmin', LOCALTIMESTAMP, 'AppAdmin' );
> 
> 
> 
> counter := counter +1;
> 
> /*if it is more than 1000 record then commit 
> and reset the counter value*/
> 
> if( counter = 1000) then
> 
> commit;
> 
> counter :=1;
> 
> end if;
> 
> end loop;
> 
> commit;
> 
> close c_company;
> 
> 
> 
> END;
> 
> $BODY$
> 
>   LANGUAGE plpgsql VOLATILE SECURITY DEFINER
> 
>   COST 100;
> 
> ALTER FUNCTION add_po_doc_hist(bigint)
> 
>   OWNER TO postgres;
> 
> 
> 
> 
> 
> 
> 
> --
> 
> 
> 
> 
> Regards,
> 
> Sachin




-- 
Sent via pgsql-general mailing list

Re: [GENERAL] PostgreSQL upgrade 9.3.4 -> 9.3.10

2016-01-12 Thread Andreas Kretschmer

Dev Kumkar  wrote:

> Hello,
> 
> 
> I want to upgrade my database from version 9.3.4 to 9.3.10.
> 
> For this task, do I need to upgrade database using pg_upgrade utility?
> http://www.postgresql.org/docs/9.3/static/pgupgrade.html

No.


> Can someone please provide more details here and also what steps needs to be
> done to upgrade to 9.3.10 level?

Just install the new version and restart PG. 


Andreas
-- 
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect.  (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly."   (unknown)
Kaufbach, Saxony, Germany, Europe.  N 51.05082°, E 13.56889°


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] WIP: CoC V2

Josh, 
> tl;dr;

> * Modified #2 to be less harsh.
> * Modified #3 with TGL and James comments
> * Did not remove examples as I believe they are vital to the success

> I saw Regina's post, I believe it is good for context but I also believe that 
> something concise and to the point is the better path.

> PostgreSQL Global Development Group (PGDG) Code of Conduct (CoC):

> 1. The CoC is to provide community guidelines for creating and enforcing a 
> safe, respectful, productive, and collaborative place for any person who is 
> willing to contribute in a safe, respectful, productive and collaborative way.

I don't know what your idea is of being "respectful and collaborative", but if 
dismissing my Coc because it's longer than your Coc and not even asking for 
comments  is your idea of collaboration, then I think we have a big problem.

Your repeat of terms in the beginning and the end looks really weird too.


Thanks,
Regina










-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] PostgreSQL upgrade 9.3.4 -> 9.3.10

2016-01-12 Thread Shulgin, Oleksandr

On Tue, Jan 12, 2016 at 10:28 AM, Dev Kumkar 
wrote:
>
> Hello,
>
>
> I want to upgrade my database from version 9.3.4 to 9.3.10.
>
> For this task, do I need to upgrade database using pg_upgrade utility?
> http://www.postgresql.org/docs/9.3/static/pgupgrade.html
>
>
> From the details it looks like for minor version upgrade pg_upgrade
utility is not required.
> "pg_upgrade (formerly called pg_migrator) allows data stored in
PostgreSQL data files to be upgraded to a later PostgreSQL major version
without the data dump/reload typically required for major version upgrades,
e.g. from 8.4.7 to the current major release of PostgreSQL. It is not
required for minor version upgrades, e.g. from 9.0.1 to 9.0.4."
>
> Can someone please provide more details here and also what steps needs to
be done to upgrade to 9.3.10 level?

Hello,

You don't need pg_upgrade for minor version upgrades.  Please refer to the
documentation: http://www.postgresql.org/docs/9.3/static/upgrading.html

"Minor releases never change the internal storage format and are always
compatible with earlier and later minor releases of the same major version
number, e.g., 8.4.2 is compatible with 8.4, 8.4.1 and 8.4.6. To update
between compatible versions, you simply replace the executables while the
server is down and restart the server. The data directory remains unchanged
— minor upgrades are that simple."

--
Alex

Re: [GENERAL] WIP: CoC V3

2016-01-12 Thread Andy Chambers

Sorry. I just saw the reference to this in the related thread.
On Jan 11, 2016 7:01 PM, "Andy Chambers"  wrote:

> Any reason not to just adopt the contributor covenant?
>
> http://contributor-covenant.org/
> tl;dr;
>
> * Removed #6 (Social Justice)
>
> PostgreSQL Global Development Group (PGDG) Code of Conduct (CoC):
>
> 1. The CoC is to provide community guidelines for creating and enforcing a
> safe, respectful, productive, and collaborative place for any person who is
> willing to contribute in a safe, respectful, productive and collaborative
> way.
>
> 2. The CoC is not about being offended. As with any diverse community,
> anyone can get offended at anything.
>
> 3. A safe, respectful, productive and collaborative environment is free of
> non-technical or personal comments, for example ones related to gender,
> sexual orientation, disability, physical appearance, body size, race or
> personal attacks.
>
> 4. Any sustained disruption of the collaborative space (mailing lists, IRC
> etc..) or other PostgreSQL events shall be construed as a violation of the
> CoC and appropriate action will be taken by the CoC committee.
>
> 5. The CoC is only about interaction with the PostgreSQL community. Your
> private and public lives outside of the PostgreSQL community are your own.
>
> Sincerely,
>
> JD
>
>
> --
> Command Prompt, Inc.  http://the.postgres.company/
>  +1-503-667-4564
> PostgreSQL Centered full stack support, consulting and development.
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

Re: [GENERAL] Code of Conduct: Is it time?

On Jan 12, 2016 9:48 AM, "Regina Obe"  wrote:
>>
>> Chris,
>>
>> >> For a Coc – I think it should be light, but make it clear that we do
not tolerate strangers coming into our group and demanding us to accept
their code, cause we want to be welcoming and show we have at least 15% of
code contributions from women.
>
>
>
> > One of the dangers of a CoC is that there are many potential issues
which may or may not become real problems.  I think if we try to be clear
on all of them, then we risk creating codes instead of a general
expectation of what we do expect.
>
> > So my question would be how do you turn this around and frame it as a
positive value and direction?
>
>
>
> > I assume respecting the commons is insufficient.  Maybe a brief note
about the fact that this is critical software and we have to maintain very
high standards of code?
>>
>>  Well we could just explain what we already do but be terse about it.
>>
>> We accept contributions from everybody.  Because our code is used in
critical software and of a complex nature, we generally prefer
contributions from members familiar with our code base, especially in core
areas.

>>
>> This generally means frequent contributors have a more likely chance of
having their code accepted or accepted faster than newcomers.
>>
>> A member of our community will inspect your contribution and if it is
unacceptable in its current state, we will make suggestions for improvement.
>>
>> In some cases, your contribution may not fit into our current
code/documentation base.  In these cases, we will reject it and explain why
it cannot be used.

I like that idea.
>>
>>
>>
>> ---

>>
>> That feels long and wordy I know, but not sure how to make it shorter.
>>
>> Thanks,
>>
>> Regina

Re: [GENERAL] Code of Conduct: Is it time?

2016-01-12 Thread Alban Hertroys

On 12 January 2016 at 09:25, Chris Travers  wrote:

> One of the dangers of a CoC is that there are many potential issues which
> may or may not become real problems.  I think if we try to be clear on all
> of them, then we risk creating codes instead of a general expectation of
> what we do expect.

Another consideration.

Last night I was thinking this issue over and then remembered that
normally very reasonable persons (which I count myself among) can
react quite poisonous when they are tired or stressed and people start
pushing their buttons. Those people probably would not be violating
any CoC rules, but can cause someone else to do so.

Moreover, some people are exceptionally good at pushing all the wrong
buttons, whether doing that willingly (out of malice) or not.
I'm a bit concerned that a CoC could give the malicious among those
the ammunition they need to push buttons of their victims. Now of
course, they could do that just as well without a CoC and I don't
recall any instances of this problem on this list.

To add to that, non-native speakers sometimes make mistakes that set
it off. I remember an embarrassing case where I thought the word
"gross" came from the German "Grosshaft", which means quite the
opposite (great, fabulous), and responded to a new idea on a list with
a heartily meant "Gross!". And then you suddenly get angry mails from
all over the place without understanding how that happened. Oops.

Where I stand? I do not know whether a CoC for PG is a good idea or
not, I can't decide. Anyway, in my case it's nothing more than an
opinion anyway - my contributions are pretty much limited to offering
help on this ML.

-- 
If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Code of Conduct: Is it time?

Chris, 

>> For a Coc – I think it should be light, but make it clear that we do not 
>> tolerate strangers coming into our group and demanding us to accept their 
>> code, cause we want to be welcoming and show we have at least 15% of code 
>> contributions from women.

 

> One of the dangers of a CoC is that there are many potential issues which may 
> or may not become real problems.  I think if we try to be clear on all of 
> them, then we risk creating codes instead of a general expectation of what we 
> do expect.

> So my question would be how do you turn this around and frame it as a 
> positive value and direction?  

 

> I assume respecting the commons is insufficient.  Maybe a brief note about 
> the fact that this is critical software and we have to maintain very high 
> standards of code? 

 Well we could just explain what we already do but be terse about it.

We accept contributions from everybody.  Because our code is used in critical 
software and of a complex nature, we generally prefer contributions from 
members familiar with our code base, especially in core areas.

This generally means frequent contributors have a more likely chance of having 
their code accepted or accepted faster than newcomers.

A member of our community will inspect your contribution and if it is 
unacceptable in its current state, we will make suggestions for improvement.

In some cases, your contribution may not fit into our current 
code/documentation base.  In these cases, we will reject it and explain why it 
cannot be used.

 

--- 


That feels long and wordy I know, but not sure how to make it shorter.

Thanks,

Regina

[GENERAL] PostgreSQL upgrade 9.3.4 -> 9.3.10

2016-01-12 Thread Dev Kumkar

Hello,


I want to upgrade my database from version 9.3.4 to 9.3.10.

For this task, do I need to upgrade database using pg_upgrade utility?
http://www.postgresql.org/docs/9.3/static/pgupgrade.html


>From the details it looks like for minor version upgrade pg_upgrade utility
is not required.
"pg_upgrade (formerly called pg_migrator) allows data stored in PostgreSQL data
files to be upgraded to a later PostgreSQL major version without the data
dump/reload typically required for major version upgrades, e.g. from 8.4.7
to the current major release of PostgreSQL. It is not required for minor
version upgrades, e.g. from 9.0.1 to 9.0.4."

Can someone please provide more details here and also what steps needs to
be done to upgrade to 9.3.10 level?

Regards...

Re: [GENERAL] Offline Tablespaces and Partial Restore

2016-01-12 Thread Pedro França

Thank you for your response David.

Yea, we are considering doing all the function calls and access to tables
with dblink and see how bad this would hurt performance. It will be tough
to explain this to the SQL Server guys.

Maybe there is another approach to deal with this kind of environment? Does
Postgres only relies on replication for high availability? Maybe an
extension that I don't know about?

Any help is appreciated.

Thank you

2016-01-11 22:11 GMT-02:00 David Steele :

> On 1/11/16 8:41 AM, Pedro França wrote:
>
>> I've tried to put the data on another database but it didn't help as
>> tablespaces are required cluster-wide on startup.
>>
>
> If putting the data in a separate database works for you then it wouldn't
> be a big leap to put it in a separate cluster. Functionality-wise it's
> pretty similar since you can't join across databases in Postgres.
>
> There are some advantages to this design since you can separate the buffer
> caches, tune optimizer variables, wal settings, etc.
>
> --
> -David
> da...@pgmasters.net
>

-- 

*PEDRO IVO* | Administrador de Banco de Dados GolSat | Líder em
Sustentabilidade

pedro.fra...@golsat.com.br  | (43) 3315.9545
| www.golsat.com.br

Re: [GENERAL] Code of Conduct: Is it time?

2016-01-12 Thread Vick Khera

On Mon, Jan 11, 2016 at 6:55 PM, Steve Litt  wrote:
> All because somebody just *had* to personally insult someone else,
> repeatedly, and nobody thought that was a bad thing, and when the
> recipient finally objected, the objection was chalked up to him or her
> valuing his/her victimhood.

+1

I was thinking along the same lines when I saw JD's original list
containing that "victimhood" line. I think that one line pretty much
eviscerates the entire purpose of having the CoC.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Code of Conduct: Is it time?

2016-01-12 Thread Neil Tiffin

> On Jan 12, 2016, at 7:50 AM, Vick Khera  wrote:
> 
> On Mon, Jan 11, 2016 at 6:55 PM, Steve Litt  wrote:
>> All because somebody just *had* to personally insult someone else,
>> repeatedly, and nobody thought that was a bad thing, and when the
>> recipient finally objected, the objection was chalked up to him or her
>> valuing his/her victimhood.
> 
> +1
> 
> I was thinking along the same lines when I saw JD's original list
> containing that "victimhood" line. I think that one line pretty much
> eviscerates the entire purpose of having the CoC.
> 

I don’t remember the “victimhood” line, but it is important to make sure people 
understand that the problem manifests itself both by being to sensitive by the 
complainer and not being sensitive enough by the group. I do believe that in 
any document it needs to be stated that everyone is expected to be tolerant of 
others.  A free society cannot exist without some level of tolerance.

Neil 

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] WIP: CoC

>> That has nothing to do with the Code of Conduct, though.
>> The community accepting Tom saying "no" to Feature X is
>> vastly different than the community not calling Tom out
>> for being mean.
>> The CoC is about the later situation and not the prior;
>> and the community should call Tom out. (I'm sure you're
>> a great person, Tom, sorry you're the example being used
>> here.)
> 
> Let me reiterate that YES it does.  The reason is that this
> is a Contributor Code of Conduct, so covers whether and how
> you accept a piece of code.

No, no it's not. It's about interpersonal interactions, not technical
decisions.

> In certain gang of 10 that has not contributed anything to our
> project can argue that you took person X over person Y's
> implementation because person Y is black and you are racist.
> If everyone is equal -- how are you going to fight that?

The same way I would argue with you if you called me sexist for not
liking your ideas? I'm not understanding your point. Why is this any
different than someone calling someone else a racist? The project
backing Tom's decision has nothing to do with responding to Tom being
called a racist. Moreover if the project backs Tom's decision on a
technical basis, the attacker isn't going to get very far with relief
here. If the attacker goes public, we point people at the exchange that
happened where Tom has presumably already discussed the reasons that the
patch/feature/ isn't being accepted.

>> Now the whole n-or-b thing gets into obvious not helpful dialogue 
>> which is not helpful.  I'm sure anyone would agree that if Tom called 
>> me a nigger, it's not helpful to our communication, and you should 
>> therefore tell him to shut-up regardless who he is.
> 
>> So then why call him more valued? It doesn't matter in this context. 
>> Why even bring it up. On technical matters, someone closer to the
>> issue is often a better arbiter of the evidence, but in matters of   
>> interpersonal interactions, no one should be held above another  
>> person.  
>   
> Tom was just an example.  Yes someone closer to the problem would be  
> better and Tom of course would delegate.  My point is people in our   
> community  are more important to us than strangers.  Let's say you
> have 1000 people come and attack you off the street(this is how those 
> SJW's work BTW and why they are so big on that line "It's your
> responsibility to oust your project maintainers").  If you consider   
> their opinions equal to those who have put sweat into the project,
> they will crush you.  A Coc is not only to make new-comers feel   
> welcome, but to protect our long-estabilished project members from
> marauders. 

I don't think I understand your point. So I get 100 friends to come here
and ask for Tom to be outed, we ask for the reason and when they don't
produce a valid one, nothing happens because none of us have any power.
When it comes to committing and governance, there _is_ a hierarchy, and
power is concentrated with a small group. The CoC isn't a place to
discuss how our development structure works. That small group of people
has no more rights against being attacked than anyone else.

Core Comitters, while extremely important to the project technically,
deserve the same respect we expect everyone to show to everyone else.
The CoC is about that respect, not settling technical disputes.

> While we do consider people's feelings, we weigh that against the Time
> and effort of changing long understood terminology that a large   
> majority of people are used to.  Since it's less costly to change new 
> terms, we are more likely to accept changes to newer terminology than 
> changes to long established industry terminology.

I'm not sure how we're on topic anymore, but "it's costly to change our
signage, we're going to continue to keep up the Nigger- and White- Only
signs above the bathroom. I hope you understand." isn't a good argument.

Moreover, I just don't believe they're actually good terms as they're
not really descriptive unless you already know what they mean, but
that's off topic.

Jim


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Offline Tablespaces and Partial Restore

2016-01-12 Thread David Steele

On 1/12/16 6:02 AM, Pedro França wrote:
> Yea, we are considering doing all the function calls and access to
> tables with dblink and see how bad this would hurt performance. It will
> be tough to explain this to the SQL Server guys.

You should consider using the Postgres FDW
(http://www.postgresql.org/docs/current/static/postgres-fdw.html).  It's
a far more elegant solution to the problem of distributed data.

> Maybe there is another approach to deal with this kind of environment?
> Does Postgres only relies on replication for high availability? Maybe an
> extension that I don't know about?

There are a number of logical replication tools (Slony, Bucardo, BDR,
etc.) but I don't see how they would help in this case (because of your
restore requirements).

-- 
-David
da...@pgmasters.net

signature.asc
Description: OpenPGP digital signature

Re: [GENERAL] PostgreSQL upgrade 9.3.4 -> 9.3.10

2016-01-12 Thread Dev Kumkar

On Tue, Jan 12, 2016 at 3:25 PM, John R Pierce  wrote:

> On 1/12/2016 1:28 AM, Dev Kumkar wrote:
>
>
> I want to upgrade my database from version 9.3.4 to 9.3.10.
>
> For this task, do I need to upgrade database using pg_upgrade utility?
> 
> http://www.postgresql.org/docs/9.3/static/pgupgrade.html
>
>
> From the details it looks like for minor version upgrade pg_upgrade
> utility is not required.
> "pg_upgrade (formerly called pg_migrator) allows data stored in PostgreSQL 
> data
> files to be upgraded to a later PostgreSQL major version without the data
> dump/reload typically required for major version upgrades, e.g. from 8.4.7
> to the current major release of PostgreSQL. It is not required for minor
> version upgrades, e.g. from 9.0.1 to 9.0.4."
>
> Can someone please provide more details here and also what steps needs to
> be done to upgrade to 9.3.10 level?
>
>
> you can do an inplace upgrade of the software, as others said, pg_upgrade
> is for upgrading from 9.X to 9.Y where Y>X
>
> however, its always a good idea to check the release notes of the version
> you're upgrading to, and seeing if there are any special issues, for
> instance, sometimes there's a potential bug in an obscure feature in said
> A.B.C version, and upgrading to A.B.D might require a reindex or
> something.
> http://www.postgresql.org/docs/current/static/release-9-3-10.html
>
> I don't see anything specifically for 9.3.4 to 9.3.10 but read it for
> yourself, following the links to the applicable intermediate release notes.
> .
>
> --
> john r pierce, recycling bits in santa cruz
>
> Thanks everyone for your quick comments, appreciate it !

Yes nothing specifically mentioned for 9.3.4 to 9.3.10

Regards...

Re: [GENERAL] Code of Conduct: Is it time?

> On 12 January 2016 at 09:25, Chris Travers  wrote:

>> One of the dangers of a CoC is that there are many potential issues 
>> which may or may not become real problems.  I think if we try to be 
>> clear on all of them, then we risk creating codes instead of a general 
>> expectation of what we do expect.

> Another consideration.

> Last night I was thinking this issue over and then remembered that normally 
> very reasonable persons (which I count myself among) can react quite 
> poisonous when they are tired or stressed and people start pushing their 
> buttons. 
> Those people probably would not be violating any CoC rules, but can cause 
> someone else to do so.
I should add you can be very hurtful without meaning to and without violating 
Coc rules.  I'm sure Josh pushing his agenda was not intentional.  
But I really felt slighted by it.

I think we are just going to have to accept that we are going to accidentally 
push each others buttons and that's okay and acceptable.  If you don't know 
someone it's even easier to push their buttons.

> Moreover, some people are exceptionally good at pushing all the wrong 
> buttons, whether doing that willingly (out of malice) or not.
> I'm a bit concerned that a CoC could give the malicious among those the 
> ammunition they need to push buttons of their victims. Now of course, they 
> could do that just as well without a CoC and I don't recall any instances of 
> this problem on this list.

Some  people - study their victims carefully and figure out where their buttons 
are so they can push them and everyone can laugh.  Considerate people study 
people in the community, figure out where their buttons are and try to avoid 
pushing them.
It's more likely a malicious person is going to be someone who doesn't 
contribute much to the project.  Thus my need to give contributors preferential 
treatment in ambiguous disputes.

> To add to that, non-native speakers sometimes make mistakes that set it off. 
> I remember an embarrassing case where I thought the word "gross" came from 
> the German "Grosshaft", 
> which means quite the opposite (great, fabulous), and responded to a new idea 
> on a list with a heartily meant "Gross!". And then you suddenly get angry 
> mails from all over the place without understanding how that happened. Oops.

It's not just non-native speakers, it's also American.  I'm from New York and 
we tend to be very blunt and make jokes about everything. I'm half Nigerian and 
Nigerian's have more than their share of people with a sick sense of humor.
Worse, my mother was a Medical Examiner (someone who does autopsies on murder 
victims) and so her humor was very death centered and I thus had this very sick 
humor that offended everyone I came across except other children 
Of medical examiners.  Those kids would make jokes when they broke their arm - 
"Go away dad, I want someone who works on living people.  I'm not dead yet."
I won't even go into the jokes Medical Examiners tell to each other as I know 
few of you could see the humor in it.

> Where I stand? I do not know whether a CoC for PG is a good idea or not, I 
> can't decide. Anyway, in my case it's nothing more than an opinion anyway - 
> my contributions are pretty much limited to offering help on this ML.
The only reason I think we need a Coc is if we are concerned that

a) Some people won't feel welcome if they don't see one
b) Malicious people will spread rumors about our project for not having one , 
but if we have one, it has to protect us from them working within the rules, 
but pushing everyone's buttons.

Thanks,
Regina

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] WIP: CoC

>  If the attacker goes public, we point people at the exchange that happened 
> where Tom has presumably already discussed the reasons that the 
> patch/feature/ isn't being accepted.

If someone wanted to out someone, they would study them carefully.  They would 
find Tom's buttons and push them.
They will show proof of Tom saying fuck you trans thing (probably something 
worse) and all that and it would  be a bad reflection on Tom and our community.
It's because they don't have a Coc that Tom is such a jerk.  They let the power 
get to his head.
They would have proof is my point in an email trail.  

Luckily I think Tom doesn't have many visible buttons to push, but others in 
our community do.
Anyrate I think it's looking more like a Coc will hurt us more than do us good. 
 This is beginning to feel too much like Highschool Lincoln-douglass debating 
which I never enjoyed.
I just want to get back to programming something useful.


> I don't think I understand your point. So I get 100 friends to come here and 
> ask for Tom to be outed, we ask for the reason and when they don't produce a 
> valid one, nothing happens because none of us have any power.
They will ask, they'll point at a random link.  Like this one - 
https://twitter.com/krainboltgreene/status/611569515315507200

You'll be too lazy to read it and assume they read it and they are right.  Tom 
will be persecuted for some link everyone was too lazy to read.
News of Tom's jerkiness would spread across the internet like a virus.  
The jerk think would be echoed by everyone until everyone believes it and takes 
it to heart. "Tom is a big jerk. How can the PostgreSQL project allow such a 
jerk to be running the show."
Tom will feel bad and think - "No good deed goes unpunished", he'll step down.

THE END


Thanks,
Regina




-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] WIP: CoC

Wow. I mean actually wow.

So many things. Just so many.

You still haven't explained why core contributors need to be treated like 
special snowflakes. If someone acts inappropriately then they should be told 
so, regardless of status. Why should we protect anyone in the wrong? 

Moreover, your scenario is so contrived and actually ends in a situation which 
supports my point, not yours.

I don't understand your point and you never clarify it. Why does how technical 
decisions are made affect how each person is suppose to treat each other 
person? We won't look past a core contributor being an ass, nor should we 
accept attacks because someone doesn't like technical decisions. None of this 
actually matters as it's all covered inside a more general CoC.

I don't want a contrived example that backs up my argument, I want you to point 
out at where my assumptions (everyone should be excellent to one another, as 
defined in a general CoC) or my chain of reasoning (core contributors are part 
of everyone, therefore interactions with and by them are covered under a 
general CoC).

"THE END" is also the most childish way to claim you're incapable of actually 
defending your argument and just want to declare yourself the winner. I'm sorry 
you don't enjoy this discussion. You're free to leave it if you wish.

Jim

On January 12, 2016 9:07:08 AM EST, Regina Obe  wrote:
>>  If the attacker goes public, we point people at the exchange that
>happened where Tom has presumably already discussed the reasons that
>the patch/feature/ isn't being accepted.
>
>If someone wanted to out someone, they would study them carefully. 
>They would find Tom's buttons and push them.
>They will show proof of Tom saying fuck you trans thing (probably
>something worse) and all that and it would  be a bad reflection on Tom
>and our community.
>It's because they don't have a Coc that Tom is such a jerk.  They let
>the power get to his head.
>They would have proof is my point in an email trail.  
>
>Luckily I think Tom doesn't have many visible buttons to push, but
>others in our community do.
>Anyrate I think it's looking more like a Coc will hurt us more than do
>us good.  This is beginning to feel too much like Highschool
>Lincoln-douglass debating which I never enjoyed.
>I just want to get back to programming something useful.
>
>
>> I don't think I understand your point. So I get 100 friends to come
>here and ask for Tom to be outed, we ask for the reason and when they
>don't produce a valid one, nothing happens because none of us have any
>power.
>They will ask, they'll point at a random link.  Like this one - 
>https://twitter.com/krainboltgreene/status/611569515315507200
>
>You'll be too lazy to read it and assume they read it and they are
>right.  Tom will be persecuted for some link everyone was too lazy to
>read.
>News of Tom's jerkiness would spread across the internet like a virus. 
>
>The jerk think would be echoed by everyone until everyone believes it
>and takes it to heart. "Tom is a big jerk. How can the PostgreSQL
>project allow such a jerk to be running the show."
>Tom will feel bad and think - "No good deed goes unpunished", he'll
>step down.
>
>THE END
>
>
>Thanks,
>Regina

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [GENERAL] Code of Conduct: Is it time?

This line has already been substantially changes. Can we keep discussion of the 
language of the WIP in the thread meant for it? This way people don't waste 
time discussing language which no longer exists.

Jim

On January 12, 2016 9:17:55 AM EST, Neil Tiffin  wrote:
>
>> On Jan 12, 2016, at 7:50 AM, Vick Khera  wrote:
>> 
>> On Mon, Jan 11, 2016 at 6:55 PM, Steve Litt
> wrote:
>>> All because somebody just *had* to personally insult someone else,
>>> repeatedly, and nobody thought that was a bad thing, and when the
>>> recipient finally objected, the objection was chalked up to him or
>her
>>> valuing his/her victimhood.
>> 
>> +1
>> 
>> I was thinking along the same lines when I saw JD's original list
>> containing that "victimhood" line. I think that one line pretty much
>> eviscerates the entire purpose of having the CoC.
>> 
>
>I don’t remember the “victimhood” line, but it is important to make
>sure people understand that the problem manifests itself both by being
>to sensitive by the complainer and not being sensitive enough by the
>group. I do believe that in any document it needs to be stated that
>everyone is expected to be tolerant of others.  A free society cannot
>exist without some level of tolerance.
>
>Neil 
>
>-- 
>Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-general

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [GENERAL] postgres user with password read-only user without?


On 01/12/2016 09:41 AM, Ted Toth wrote:

Is there a way to configure authentication so that some users require
a password and other users don't?


Yes, see:

http://www.postgresql.org/docs/9.4/interactive/auth-pg-hba-conf.html

"user

Specifies which database user name(s) this record matches. The 
value all specifies that it matches all users. Otherwise, this is either 
the name of a specific database user, or a group name preceded by +. 
(Recall that there is no real distinction between users and groups in 
PostgreSQL; a + mark really means "match any of the roles that are 
directly or indirectly members of this role", while a name without a + 
mark matches only that specific role.) For this purpose, a superuser is 
only considered to be a member of a role if they are explicitly a member 
of the role, directly or indirectly, and not just by virtue of being a 
superuser. Multiple user names can be supplied by separating them with 
commas. A separate file containing user names can be specified by 
preceding the file name with @.

"



Ted





--
Adrian Klaver
adrian.kla...@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] postgres user with password read-only user without?

2016-01-12 Thread David G. Johnston

On Tue, Jan 12, 2016 at 10:41 AM, Ted Toth  wrote:

> Is there a way to configure authentication so that some users require
> a password and other users don't?
>

Yes.

http://www.postgresql.org/docs/current/static/auth-pg-hba-conf.html

David J.

Re: [GENERAL] WIP: CoC


On 01/12/2016 08:17 AM, Neil Tiffin wrote:



On Jan 12, 2016, at 12:20 AM, Tom Lane  wrote:

[ just a few comments on specific points ]

"Greg Sabino Mullane"  writes:

2. The CoC is not about being offended. The act of being offended is
purely a recipient response and usually the offended individual is more
interested in being a victim than moving forward.



Too defensive; not needed in the code of conduct.


Agreed, let's avoid defensiveness here.  There's not much advantage to
this whole exercise unless we can be welcoming rather than dismissive.



How about a simple statement?

2. We expect people to be both tolerant and respectful of others.

Neil


For those who are new to the party, the actual latest revision of this 
is over on $SUBJECT: WIP: CoC v4


Jd


--
Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] WIP: CoC V4

2016-01-12 Thread Jim Mlodgenski

On Tue, Jan 12, 2016 at 11:50 AM, Joshua D. Drake 
wrote:

> Tl;dr;
>
> * Removed specific examples and reworded #3 to be more concise
>
> PostgreSQL Global Development Group (PGDG) Code of Conduct (CoC):
>
> 1. The CoC is to provide community guidelines for creating and enforcing a
> safe, respectful, productive, and collaborative place for any person who is
> willing to contribute in a safe, respectful, productive and collaborative
> way.
>
> 2. The CoC is not about being offended. As with any diverse community,
> anyone can get offended at anything.
>

Maybe add a little to #2.

"Assume positive intent from your fellow community member."


>
> 3. A safe, respectful, productive and collaborative environment is free of
> personal attacks and disparaging remarks of any kind.
>
> 4. Any sustained disruption of the collaborative space (mailing lists, IRC
> etc..) or other PostgreSQL events shall be construed as a violation of the
> CoC and appropriate action will be taken by the CoC committee.
>
> 5. The CoC is only about interaction with the PostgreSQL community. Your
> private and public lives outside of the PostgreSQL community are your own.
>
> --
> Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
> PostgreSQL Centered full stack support, consulting and development.
> Announcing "I'm offended" is basically telling the world you can't
> control your own emotions, so everyone else should do it for you.
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

[GENERAL] Moving a large DB (> 500GB) to another DB with different locale

Hi all.
 
I'm moving a > 500GB DB to another server which is initdb'ed with a different 
locale (nb_NO.UTF-8 to get correct collation when ORDER BY).
Is there another option than pg_dump/restore for doing this?
 
Thanks.
 
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andr...@visena.com 
www.visena.com

Re: [GENERAL] Slow Query - PostgreSQL 9.2

2016-01-12 Thread Saulo Merlo

UPDATED:
Index created:create index concurrently inode_segments_st_ino_target_pidx on 
gorfs.inode_segments (st_ino desc, st_ino_target desc) where nfs_migration_date 
is null;
NEW EXPLAIN ANALYZE:http://explain.depesz.com/s/Swu
I also am able to create a temporary table to store migrations, which may be 
the best option (no longer need to join new columns in query)
If you could help with that as well..Thank you
gorfs.nodes is a view:
CREATE OR REPLACE VIEW gorfs.nodes AS  SELECT "p"."full_path" AS 
"node_full_path", "h"."st_ino" AS "parent_inode_id", "t"."st_ino" AS 
"inode_id", CASEWHEN "p"."st_ino_target"::bigint = 2 THEN 
NULL::character varyingELSE "p"."segment_index"::character varying  
  END AS "relative_path", "t"."st_mode"::bigint AS "raw_mode", 
"f"."constant_name" AS "object_type", 
("gorfs"."mode_t_bits"('S_ISUID'::"gorfs"."mode_t_constant_name")::"bit" & 
"t"."st_mode"::"bit")::integer <> 0 AS "setuid", 
("gorfs"."mode_t_bits"('S_ISGID'::"gorfs"."mode_t_constant_name")::"bit" & 
"t"."st_mode"::"bit")::integer <> 0 AS "setgid", 
("gorfs"."mode_t_bits"('S_ISVTX'::"gorfs"."mode_t_constant_name")::"bit" & 
"t"."st_mode"::"bit")::integer <> 0 AS "sticky", 
"right"("concat"((("gorfs"."mode_t_bits"('S_IRWXU'::"gorfs"."mode_t_constant_name")::"bit"
 | "gorfs"."mode_t_bits"('S_IRWXG'::"gorfs"."mode_t_constant_name")::"bit") | 
"gorfs"."mode_t_bits"('S_IRWXO'::"gorfs"."mode_t_constant_name")::"bit") & 
"t"."st_mode"::"bit"), 9)::bit(9) AS "permissions", "t"."st_nlink" AS 
"links_count", "t"."st_uid" AS "owner_uid", "t"."st_gid" AS "owner_gid", 
"t"."st_size" AS "data_length", "t"."st_atime" AS "last_accessed", 
"t"."st_mtime" AS "last_modified", "t"."st_ctime" AS "last_changed", 
"t"."checksum_md5", ("mst"."media_type" || '/'::"text") || 
"mst"."subtype_string"::"text" AS "media_type", CASEWHEN 
"f"."constant_name" = 'S_IFLNK'::"gorfs"."mode_t_constant_name" THEN ( SELECT 
"convert_from"("ls"."segment_data", 'UTF8'::"name") AS "convert_from"   
FROM "gorfs"."inode_segments" "ls"  WHERE "ls"."st_ino"::bigint 
= "p"."st_ino_target"::bigint)ELSE NULL::"text"END AS 
"target", CASEWHEN "f"."constant_name" = 
'S_IFREG'::"gorfs"."mode_t_constant_name" THEN ( SELECT 
"string_agg"("fs"."segment_data", ''::"bytea" ORDER BY "fs"."segment_index") AS 
"string_agg"   FROM "gorfs"."inode_segments" "fs"  
WHERE "fs"."st_ino"::bigint = "p"."st_ino_target"::bigint)ELSE 
NULL::"bytea"END AS "file_data", "t"."external_size" IS NOT NULL AS 
"is_external", "t"."external_size" AS "data_length_target"   FROM 
"gorfs"."inode_segments" "p"   JOIN "gorfs"."dir_inodes" "h" ON 
"h"."st_ino"::bigint = "p"."st_ino"::bigint   JOIN "gorfs"."inodes" "t" ON 
"t"."st_ino"::bigint = "p"."st_ino_target"::bigint   JOIN 
"gorfs"."mode_t_flags"() "f"("constant_name", "description", "bits", 
"bits_octal", "bits_hex", "bits_decimal") ON "f"."bits"::"bit" = 
("gorfs"."mode_t_bits"('S_IFMT'::"gorfs"."mode_t_constant_name")::"bit" & 
"t"."st_mode"::"bit")   LEFT JOIN "media_subtypes" "mst" ON 
"mst"."media_subtype_id" = "t"."media_subtype_id";
gorfs.inode_segments:


 Table "gorfs.inode_segments"   Column   | 
Type | 
Modifiers+--+--- st_ino 
| "gorfs"."ino_t"  | not null segment_index  | 
"gorfs"."pathname_component" | not null st_ino_target  | "gorfs"."ino_t"
  | full_path  | "gorfs"."absolute_pathname"  | segment_data
   | "bytea"  | nfs_migration_date | timestamp with time 
zone | nfs_file_path  | "text"   |Indexes:
"pk_inode_segments" PRIMARY KEY, "btree" ("st_ino", "segment_index")
"uc_no_duplicate_full_paths" UNIQUE CONSTRAINT, "btree" ("full_path")
"inode_segments_st_ino_target_pidx" "btree" ("st_ino" DESC, "st_ino_target" 
DESC) WHERE "nfs_migration_date" IS NULL"ix_inode_segments_climb_tree" 
"btree" ("segment_index", "st_ino_target")
"ix_inode_segments_filter_by_subtree" "btree" ("full_path" 
"varchar_pattern_ops") WHERE "full_path" IS NOT NULL
"ix_inode_segments_full_path_resolution" "btree" ("st_ino", "full_path")
"ix_inode_segments_gsdi_pk" "btree" (("st_ino"::"text"), 
("segment_index"::"text"))"ix_inode_segments_ja_files_lookup" "btree" 
((CASEWHEN "full_path"::"text" ~ '/[^/]*\.[^/]*$'::"text" THEN 
"upper"("regexp_replace"("full_path"::"text", '.*\.'::"text", ''::"text", 
'g'::"text"))ELSE NULL::"text"END)) WHERE 
"gorfs"."is_kaminski_note_path"("full_path"::"text")
"ix_inode_segments_nfs_file_path" "btree" ("full_path")
"ix_inode_segments_nfs_migration_date" "btree" ("nfs_migration_date") WHERE 
"nfs_migration_date" IS NULL"ix_inode_segments_nfs_st_ino" "btree"

Re: [GENERAL] WIP: CoC V4


On 01/12/2016 12:16 PM, Oleg Bartunov wrote:


4. Any sustained disruption of the collaborative space (mailing
lists, IRC etc..) or other PostgreSQL events shall be construed as a
violation of the CoC and appropriate action will be taken by the CoC
committee.


Then we need to define what is "Coc committee".


Yes but I believe that can be done AFTER...




5. The CoC is only about interaction with the PostgreSQL community.
Your private and public lives outside of the PostgreSQL community
are your own.



* We should specify here legal place of CoC, say, URL on postgresql.org

* We should translate it to other languages


Agreed.

JD

--
Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Moving a large DB (> 500GB) to another DB with different locale

2016-01-12 Thread John R Pierce


On 1/12/2016 1:20 PM, Andreas Joseph Krogh wrote:
I'm moving a > 500GB DB to another server which is initdb'ed with a 
different locale (nb_NO.UTF-8 to get correct collation when ORDER BY).

Is there another option than pg_dump/restore for doing this?


nope, because the text data has to be converted to the new encoding, 
indexes rebuilt since the collation order is different, etc.




--
john r pierce, recycling bits in santa cruz



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] WIP: CoC V5


tl;dr;

* Moved #2 to #3 and #3 to #2
* Added wording for assuming positive intent to #2

PostgreSQL Global Development Group (PGDG) Code of Conduct (CoC):

1. The CoC is to provide community guidelines for creating and enforcing 
a safe, respectful, productive, and collaborative place for any person 
who is willing to contribute in a safe, respectful, productive and 
collaborative way.


2. A safe, respectful, productive and collaborative environment is free 
of personal attacks and disparaging remarks of any kind.


3. The CoC is not about being offended. One should always assume good 
intentions. As with any diverse community, anyone can get offended at 
anything.


4. Any sustained disruption of the collaborative space (mailing lists, 
IRC etc..) or other PostgreSQL events shall be construed as a violation 
of the CoC and appropriate action will be taken by the CoC committee.


5. The CoC is only about interaction with the PostgreSQL community. Your 
private and public lives outside of the PostgreSQL community are your own.




--
Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Moving a large DB (> 500GB) to another DB with different locale

På tirsdag 12. januar 2016 kl. 22:56:56, skrev John R Pierce <
pie...@hogranch.com >:
On 1/12/2016 1:20 PM, Andreas Joseph Krogh wrote:
 > I'm moving a > 500GB DB to another server which is initdb'ed with a
 > different locale (nb_NO.UTF-8 to get correct collation when ORDER BY).
 > Is there another option than pg_dump/restore for doing this?

 nope, because the text data has to be converted to the new encoding,
 indexes rebuilt since the collation order is different, etc.

I was pretty sure there wasn't, but had to ask before imposing downtime on our 
customers.

Thanks.

-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andr...@visena.com 
www.visena.com

Re: [GENERAL] Code of Conduct: Is it time?

2016-01-12 Thread Achilleas Mantzios

On 05/01/2016 18:47, Joshua D. Drake wrote:

Hello,

I had a hard time writing this email. I think Code of Conducts are non-essential, a waste of respectful people's time and frankly if you are going to be a jerk, our community will call you out on
it. Unfortunately a lot of people don't agree with that. I have over the course of the last year seen more and more potential users very explicitly say, "I will not contribute to a project or attend
a conference that does not have a CoC".

Some of us may be saying, "Well we don't want those people". I can't argue with some facts though. Ubuntu has had a CoC[1] since the beginning of the project and they grew exceedingly quick. Having
walls in the hallway of interaction isn't always a bad thing.

In reflection, the only thing a CoC does is put in writing what behaviour we as
a project already require, so why not document it and use it as a tool to
encourage more contribution to our project?

Sincerely,

1. http://www.ubuntu.com/about/about-ubuntu/conduct

Well, while I don't have an opinion, since after 16+ years I don't think I am
going anywhere away from PostgreSQL, let me share my initial feelings about the
community.
It was back in 2003, having spent already 3 years with the database and just starting to implement our own hierarchical solution based on postgresql arrays and intarray contrib module, and heavily
hack DBMirror, when someone (high ranking) on -sql called me "newbie".
My immediate reaction was to start looking for alternatives. Obviously I failed (no OS DB was this good). Other times I had my favorite OS (FreeBSD) being bashed by pgsql ppl, but held on, I am still
here, and ppl at pgsql conferences now talk about a company who has deployed over 100 pgsql installations in the seven seas communicating over satellite by a hacked version of uucp and replicated via
a heavily hacked version of DBmirror.

So while I think that a CoC might help beginners stay, I don't think that this
is a major part, neither do I think that the ppl themselves will easily conform.

--
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

German, was: Re: [GENERAL] Code of Conduct: Is it time?

2016-01-12 Thread Karsten Hilbert

> To add to that, non-native speakers sometimes make mistakes that set
> it off. I remember an embarrassing case where I thought the word
> "gross" came from the German "Grosshaft", which means quite the
> opposite (great, fabulous), and responded to a new idea on a list with
> a heartily meant "Gross!".

Indeed, that German word would be "großartig!" (often spelled "grossartig"
especially in environments without easy access to the German "ß".

Responding "Gross!" would amount to saying "That's a great idea in that
it is all-encompassing and using a generic concept to nicely solve a
specific (class of) problem(s) and then some.". Entirely reasonable (if
a bit unusually worded) in German :-)

Karsten Hilbert


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] WIP: CoC V4

2016-01-12 Thread Oleg Bartunov

On Tue, Jan 12, 2016 at 7:50 PM, Joshua D. Drake 
wrote:

> Tl;dr;
>
> * Removed specific examples and reworded #3 to be more concise
>
> PostgreSQL Global Development Group (PGDG) Code of Conduct (CoC):
>
> 1. The CoC is to provide community guidelines for creating and enforcing a
> safe, respectful, productive, and collaborative place for any person who is
> willing to contribute in a safe, respectful, productive and collaborative
> way.
>
> 2. The CoC is not about being offended. As with any diverse community,
> anyone can get offended at anything.
>
> 3. A safe, respectful, productive and collaborative environment is free of
> personal attacks and disparaging remarks of any kind.
>
> 4. Any sustained disruption of the collaborative space (mailing lists, IRC
> etc..) or other PostgreSQL events shall be construed as a violation of the
> CoC and appropriate action will be taken by the CoC committee.
>

Then we need to define what is "Coc committee".


>
> 5. The CoC is only about interaction with the PostgreSQL community. Your
> private and public lives outside of the PostgreSQL community are your own.
>


* We should specify here legal place of CoC, say, URL on postgresql.org
* We should translate it to other languages




>
> --
> Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
> PostgreSQL Centered full stack support, consulting and development.
> Announcing "I'm offended" is basically telling the world you can't
> control your own emotions, so everyone else should do it for you.
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

Re: [GENERAL] 9.4 -> 9.5 upgrade problem when both python2 and python3 present

2016-01-12 Thread Paul Jones

On Mon, Jan 11, 2016 at 06:23:06PM -0500, Tom Lane wrote:
> Date: Mon, 11 Jan 2016 18:23:06 -0500
> From: Tom Lane 
> To: Paul Jones 
> cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] 9.4 -> 9.5 upgrade problem when both python2 and
>  python3 present
> 
> 
> > I guess the thing to do is to manually pg_dump the databases that have
> > python, drop them, upgrade, and then manually restore.
> 
> If you'd rather build a patched version of PG, I have posted a
> work-in-progress patch to address this issue:
> http://www.postgresql.org/message-id/31659.1452538...@sss.pgh.pa.us

It worked most excellently, thank you.

> 
>   regards, tom lane


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Code of Conduct: Is it time?

2016-01-12 Thread John R Pierce


On 1/12/2016 5:42 AM, Regina Obe wrote:

a) Some people won't feel welcome if they don't see one
b) Malicious people will spread rumors about our project for not having one , 
but if we have one, it has to protect us from them working within the rules, 
but pushing everyone's buttons.


c) and if we DO have one, malicious people will try and either work 
around perceived cracks in said CoC, or use the CoC against people in 
malicious ways, just because they can.   Trolls be Trolls



--
john r pierce, recycling bits in santa cruz



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] plv8 binaries for PostgreSQL 9.5 on Windows


On 01/11/2016 05:50 PM, Igal @ Lucee.org wrote:

Where can I find binaries for plv8 for PostgreSQL 9.5 for Windows?


The only Windows binaries I could find where for 9.4, here:

http://www.postgresonline.com/journal/archives/341-PLV8-binaries-for-PostgreSQL-9.4-windows-both-32-bit-and-64-bit.html

Maybe you could contact the authors and see if they are going to build 
9.5 versions?




Thanks,

--

Igal Sapir
Lucee Core Developer
Lucee.org 




--
Adrian Klaver
adrian.kla...@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] PostgreSQL upgrade 9.3.4 -> 9.3.10

On 01/12/2016 01:37 AM, Shulgin, Oleksandr wrote:

On Tue, Jan 12, 2016 at 10:28 AM, Dev Kumkar > wrote:
 >
 > Hello,
 >
 >
 > I want to upgrade my database from version 9.3.4 to 9.3.10.
 >
 > For this task, do I need to upgrade database using pg_upgrade utility?
 > http://www.postgresql.org/docs/9.3/static/pgupgrade.html
 >
 >
 > From the details it looks like for minor version upgrade pg_upgrade
utility is not required.
 > "pg_upgrade (formerly called pg_migrator) allows data stored in
PostgreSQL data files to be upgraded to a later PostgreSQL major version
without the data dump/reload typically required for major version
upgrades, e.g. from 8.4.7 to the current major release of PostgreSQL. It
is not required for minor version upgrades, e.g. from 9.0.1 to 9.0.4."
 >
 > Can someone please provide more details here and also what steps
needs to be done to upgrade to 9.3.10 level?

Hello,

You don't need pg_upgrade for minor version upgrades.  Please refer to
the documentation: http://www.postgresql.org/docs/9.3/static/upgrading.html

"Minor releases never change the internal storage format and are always
compatible with earlier and later minor releases of the same major
version number, e.g., 8.4.2 is compatible with 8.4, 8.4.1 and 8.4.6. To
update between compatible versions, you simply replace the executables
while the server is down and restart the server. The data directory
remains unchanged — minor upgrades are that simple."

While that is the rule, there have been exceptions, one I could find:

http://www.postgresql.org/docs/9.1/interactive/release-8-0-3.html

Per another post down thread, the prudent thing to do is to read the 
Release Notes for each release.

--
Alex

--
Adrian Klaver
adrian.kla...@aklaver.com

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] WIP: CoC

James,

 

I was describing a real live scenario.  I was describing what happened to Linus 
Torvalds.  Only part was he hasn't left yet.  He's stood his ground and ignored 
the tyrants.

 

Remember I'm on the side of not having a Coc.  I have trouble debating things I 
don't believe in.  I was just doing it to say – if we must have a Coc, let it 
be a Cock like mine and not a Vagina like what Josh proposed.

 

Anyrate I think we have debated this enough to say.  We considered having a Coc 
and concluded it's not in our best interest.  And when the hounds come thru 
with something like this:

 

https://github.com/solidusio/solidus/pull/643#issuecomment-168749932

 

We can point at the long several threads in which we discussed the issue 
extensively and got all confused which thread to follow.

 

They can analyze the post-mortem in their law studies and analyze why all of us 
had such opposing view points and couldn't even agree with each other.

 

Thanks,

Regina

 

From: James Keener [mailto:j...@jimkeener.com] 
Sent: Tuesday, January 12, 2016 9:20 AM
To: Regina Obe ; 'Psql_General (E-mail)' 

Subject: RE: WIP: CoC

 

Wow. I mean actually wow.

So many things. Just so many.

You still haven't explained why core contributors need to be treated like 
special snowflakes. If someone acts inappropriately then they should be told 
so, regardless of status. Why should we protect anyone in the wrong? 

Moreover, your scenario is so contrived and actually ends in a situation which 
supports my point, not yours.

I don't understand your point and you never clarify it. Why does how technical 
decisions are made affect how each person is suppose to treat each other 
person? We won't look past a core contributor being an ass, nor should we 
accept attacks because someone doesn't like technical decisions. None of this 
actually matters as it's all covered inside a more general CoC.

I don't want a contrived example that backs up my argument, I want you to point 
out at where my assumptions (everyone should be excellent to one another, as 
defined in a general CoC) or my chain of reasoning (core contributors are part 
of everyone, therefore interactions with and by them are covered under a 
general CoC).

"THE END" is also the most childish way to claim you're incapable of actually 
defending your argument and just want to declare yourself the winner. I'm sorry 
you don't enjoy this discussion. You're free to leave it if you wish.

Jim

On January 12, 2016 9:07:08 AM EST, Regina Obe  > wrote:

  If the attacker goes public, we point people at the exchange that happened 
where Tom has presumably already discussed the reasons that the 
patch/feature/ isn't being accepted.


If someone wanted to out someone, they would study them carefully.  They would 
find Tom's buttons and push them.
They will show proof of Tom saying fuck you trans thing (probably something 
worse) and all that and it would  be a bad reflection on Tom and our community.
It's because they don't have a Coc that Tom is such a jerk.  They let the power 
get to his head.
They would have proof is my point in an email trail.  

Luckily I think Tom doesn't have many visible buttons to push, but others in 
our community do.
Anyrate I think it's looking more like a Coc will hurt us more than do us good. 
 This is beginning to
feel too much like Highschool Lincoln-douglass debating which I never enjoyed.
I just want to get back to programming something useful.



 I don't think I understand your point. So I get 100 friends to come here and 
ask for Tom to be outed, we ask for the reason and when they don't produce a 
valid one, nothing happens because none of us have any power.

They will ask, they'll point at a random link.  Like this one - 
https://twitter.com/krainboltgreene/status/611569515315507200

You'll be too lazy to read it and assume they read it and they are right.  Tom 
will be persecuted for some link everyone was too lazy to read.
News of Tom's jerkiness would spread across the internet like a virus.  
The jerk think would be echoed by
everyone until everyone believes it and takes it to heart. "Tom is a big jerk. 
How can the PostgreSQL project allow such a jerk to be running the show."
Tom will feel bad and think - "No good deed goes unpunished", he'll step down.

THE END


Thanks,
Regina




-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [GENERAL] WIP: CoC

> everyone should be excellent to one another, as defined in a general CoC

 

I think CoralineAda has debated extensively why being excellent is not 
sufficient.

 

https://modelviewculture.com/pieces/codes-of-conduct-when-being-excellent-is-not-enough

 

I personally don't have the patience to read that dribble.

Thanks,

Regina

Re: [GENERAL] WIP: CoC

>
>
> https://modelviewculture.com/pieces/codes-of-conduct-when-being-excellent-is-not-enough
>
That post seems to discuss why a written CoC is needed (as opposed to an
unwritten "act professional" one). I don't believe it applies to my
comment.

Re: [GENERAL] Giving error for function

Sachin Srivastava  writes:
> I am getting the below error while I am running the below function
> "add_po_doc_hist", for "c_company" cursor, please suggest what is wrong
> with code.
> ERROR:  relation "c_company" does not exist
> CONTEXT:  compilation of PL/pgSQL function "add_po_doc_hist" near line 11

> CREATE OR REPLACE FUNCTION add_po_doc_hist(subscriberid bigint)
>   RETURNS void AS
> $BODY$
> DECLARE
> --Select All Companies for the subscriber entered
> c_company CURSOR FOR
> SELECT company_id
> from PSM_COMPANY_PROFILE
> where is_BUYER = 1
>   and subscriber_id=subscriberID;
> v_company c_company%ROWTYPE;

The error is pointing you here.  I believe the problem is that c_company
is a cursor, not a table, and as such can't be referenced with %rowtype.

I think you could just use RECORD instead ...

regards, tom lane


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Text parameter is treated as sql query in postgresql function


On 01/11/2016 11:47 PM, Yash Gajbhiye wrote:

I am using postgres crosstab() function to create a table.

My first dynamic query function (dynamic_crosstab) creates a sql select
statement containing crosstab(), and then this select statement gives
the final result on execution. /*dynamic_crosstab functions works
perfectly*/

I need to execute this select query (result of dynamic_crosstab
function) by using parameters, so I am again using a function as follows.


CREATE OR REPLACE FUNCTION leavetypeaccrual(

cur refcursor,

 text,

 text,

 text)

   RETURNS SETOF refcursor AS

$BODY$

declare

val_1 text;

begin

select * from dynamic_crosstab($ select

p.location_id, p.employee_id, pt.description, sum(p.hours_allocated) as
hours_allocated


I am having a hard figuring out what the above is supposed to be doing, 
in particular this?:


$ select

p.location_id, p.employee_id, pt.description, sum(p.hours_allocated) as 
hours_allocated ...


Why the leading $?

Would it be possible to cut and paste the errors in the future, I had to 
enlarge the images to get these old eyes to see the issue. At any rate 
from what I could see, it is a quoting issue, which I believe is related 
to the question above.





from

preference_type pt, preference p, preference_date_etl pde, date_etl de

where

pt.id  = p.preference_type_id and

pde.preference_id = p.id  and

pde.corporation_id = $4 and

de.id  = pde.date_etl_id and

pde.deleted = ''N'' and

p.deleted = ''N'' and

pt.deleted = ''N'' and

de.local_date between ''$2'' and ''$3'' and

p.employee_id IN (

select id from employee where user_id IN ( select id from app_user where
corporation_id =||$4||))

group by p.location_id, p.employee_id, pt.description $,

$ select distinct description from preference_type where deleted =''N''
and corporation_id=$ || $4,

'text','location_id int , employee_id int',false)  into val_1;

open cur for execute val_1;

return next cur;

end;

$BODY$


Now this function should execute the crosstab() function and it does
when I use deleted= 'N' in the second parameter but shows error because
crosstab() needs deleted=''N'' to execute.

Inline image 1

And I need to use deleted=''N'' to get my results but postgres treats my
second parameter as a individual query when I try to do it.

Inline image 2

The first parameter is passed perfectly with deleted =''N''  but
postgres does not recognize second parameter when deleted=''N''.

Please suggest what modifications I should do to make this work.


Thanks.


--
Yash Gajbhiye




--
Adrian Klaver
adrian.kla...@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] WIP: CoC

2016-01-12 Thread Bret Stern

On Tue, 2016-01-12 at 09:07 -0500, Regina Obe wrote:

> >  If the attacker goes public, we point people at the exchange that happened 
> > where Tom has presumably already discussed the reasons that the 
> > patch/feature/ isn't being accepted.
> 
> If someone wanted to out someone, they would study them carefully.  They 
> would find Tom's buttons and push them.
> They will show proof of Tom saying fuck you trans thing (probably something 
> worse) and all that and it would  be a bad reflection on Tom and our 
> community.
> It's because they don't have a Coc that Tom is such a jerk.  They let the 
> power get to his head.
> They would have proof is my point in an email trail.  
> 
> Luckily I think Tom doesn't have many visible buttons to push, but others in 
> our community do.
> Anyrate I think it's looking more like a Coc will hurt us more than do us 
> good.  This is beginning to feel too much like Highschool Lincoln-douglass 
> debating which I never enjoyed.
> I just want to get back to programming something useful.
> 

Amen.

> 
> > I don't think I understand your point. So I get 100 friends to come here 
> > and ask for Tom to be outed, we ask for the reason and when they don't 
> > produce a valid one, nothing happens because none of us have any power.
> They will ask, they'll point at a random link.  Like this one - 
> https://twitter.com/krainboltgreene/status/611569515315507200
> 
> You'll be too lazy to read it and assume they read it and they are right.  
> Tom will be persecuted for some link everyone was too lazy to read.
> News of Tom's jerkiness would spread across the internet like a virus.  
> The jerk think would be echoed by everyone until everyone believes it and 
> takes it to heart. "Tom is a big jerk. How can the PostgreSQL project allow 
> such a jerk to be running the show."
> Tom will feel bad and think - "No good deed goes unpunished", he'll step down.
> 
> THE END
> 
> 
> Thanks,
> Regina
> 

In that vein..Being the insensitive MF that I am, I don't care what Tom
says. Toms value (in the list) is his commitment to
the project and (for me) the last word on most topics..even if he is a
liberal sob.
Feel the love,
Bret Stern


> 
>

Re: [GENERAL] WIP: CoC

Bret,

Thanks.  That made me feel much better.  

I was about to walk out the door never to use PostgreSQL lists again because I 
thought Josh was an insensitive jerk flapping his wings about "respectful, 
collaborative"

, and I certainly violated the new "respectful" mantra buy calling his Coc a 
Vagina.

I was beginning to feel like everyone was against me.  

Love,

Regina

From: Bret Stern [mailto:bret_st...@machinemanagement.com] 
Sent: Tuesday, January 12, 2016 11:01 AM
To: Regina Obe 
Cc: 'James Keener' ; 'Psql_General (E-mail)' 

Subject: Re: [GENERAL] WIP: CoC

On Tue, 2016-01-12 at 09:07 -0500, Regina Obe wrote: 

>  If the attacker goes public, we point people at the exchange that happened 
> where Tom has presumably already discussed the reasons that the 
> patch/feature/ isn't being accepted.

If someone wanted to out someone, they would study them carefully.  They would 
find Tom's buttons and push them.
They will show proof of Tom saying fuck you trans thing (probably something 
worse) and all that and it would  be a bad reflection on Tom and our community.
It's because they don't have a Coc that Tom is such a jerk.  They let the power 
get to his head.
They would have proof is my point in an email trail.  

Luckily I think Tom doesn't have many visible buttons to push, but others in 
our community do.
Anyrate I think it's looking more like a Coc will hurt us more than do us good. 
 This is beginning to feel too much like Highschool Lincoln-douglass debating 
which I never enjoyed.
I just want to get back to programming something useful.

Amen. 

> I don't think I understand your point. So I get 100 friends to come here and 
> ask for Tom to be outed, we ask for the reason and when they don't produce a 
> valid one, nothing happens because none of us have any power.
They will ask, they'll point at a random link.  Like this one - 
https://twitter.com/krainboltgreene/status/611569515315507200

You'll be too lazy to read it and assume they read it and they are right.  Tom 
will be persecuted for some link everyone was too lazy to read.
News of Tom's jerkiness would spread across the internet like a virus.  
The jerk think would be echoed by everyone until everyone believes it and takes 
it to heart. "Tom is a big jerk. How can the PostgreSQL project allow such a 
jerk to be running the show."
Tom will feel bad and think - "No good deed goes unpunished", he'll step down.

THE END

Thanks,
Regina

In that vein..Being the insensitive MF that I am, I don't care what Tom says. 
Toms value (in the list) is his commitment to
the project and (for me) the last word on most topics..even if he is a liberal 
sob.
Feel the love,
Bret Stern

Re: [GENERAL] Moving a large DB (> 500GB) to another DB with different locale

På tirsdag 12. januar 2016 kl. 23:28:55, skrev Tom Lane >:
Andreas Joseph Krogh  writes:
 > P�� tirsdag 12. januar 2016 kl. 22:56:56, skrev John R Pierce <
 > pie...@hogranch.com >:
 >> On 1/12/2016 1:20 PM, Andreas Joseph Krogh wrote:
 >>> I'm moving a > 500GB DB to another server which is initdb'ed with a
 >>> different locale (nb_NO.UTF-8 to get correct collation when ORDER BY).
 >>> Is there another option than pg_dump/restore for doing this?

 >>  nope, because the text data has to be converted to the new encoding,
 >>  indexes rebuilt since the collation order is different, etc.

 > I was pretty sure there wasn't, but had to ask before imposing downtime on 
our
 > customers.

 If you're only changing collation and not encoding, then in principle you
 could move the tables over and then reindex each collation-sensitive
 index.  pg_upgrade has no ability to do that for you though, which would
 make it an error-prone manual process.  Also, it'd be far from
 zero-downtime since you still gotta rebuild a lot of indexes.

 regards, tom lane

This is interessting.
I'm only changin collation, the encoding (UTF-8) is the same. I'm replacing 
the packaged PG's version of initdb (resulting in en_US.UTF-8) with:
/usr/lib/postgresql/9.5/bin/initdb --locale=nb_NO.UTF-8 -D 
/var/lib/postgresql/9.5/main

Are you saying that I don't have to re-initdb and can just change collation 
somehow? If so, how?

pg_upgrade + re-indexing is much preferred instead of the 10+ hours the 
pg_dump/restore would take (SSD-disks).

Thanks.

-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andr...@visena.com 
www.visena.com

Re: [GENERAL] Moving a large DB (> 500GB) to another DB with different locale

Andreas Joseph Krogh  writes:
> Are you saying that I don't have to re-initdb and can just change collation 
> somehow? If so, how?

Collation is really pretty much a per-index property these days; the
DB-level setting only provides a default.  You could imagine some
process along the lines of:

1. For each collation-sensitive index, use CREATE INDEX CONCURRENTLY
to build a new index with same properties except for collation.

2. Change the DB-level setting so that ORDER BY acquires the new
default interpretation (I assume you don't want to attach an explicit
COLLATE to every ORDER BY for the rest of time, else you wouldn't
need to do this).  I think you'd have to poke pg_database.datcollate
and datctype directly as a superuser for this to happen, but AFAIR
there's not any underlying magic that would prevent it from working.

3. Drop all the now-useless indexes with the old collation.

One fly in the ointment is that step 1 would result in indexes marked
with indcollate equal to the explicitly chosen collation.  There was
just some discussion the other day about how the planner wouldn't
recognize that this is equivalent to COLLATE "default", so after 2
you might also need a step that runs through pg_index and updates
the collation OIDs to match the "default" collation.

Obviously, this is untested and you'd be foolish not to try it out
on a test installation before believing that it works.  But I think
it might, and if you are looking at a seriously painful dump+reload
it'd be worth the trouble to debug a process for it.

regards, tom lane

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Moving a large DB (> 500GB) to another DB with different locale

På tirsdag 12. januar 2016 kl. 23:49:24, skrev Tom Lane >:
Andreas Joseph Krogh  writes:
 > Are you saying that I don't have to re-initdb and can just change collation
 > somehow? If so, how?

 Collation is really pretty much a per-index property these days; the
 DB-level setting only provides a default.  You could imagine some
 process along the lines of:

 1. For each collation-sensitive index, use CREATE INDEX CONCURRENTLY
 to build a new index with same properties except for collation.

 2. Change the DB-level setting so that ORDER BY acquires the new
 default interpretation (I assume you don't want to attach an explicit
 COLLATE to every ORDER BY for the rest of time, else you wouldn't
 need to do this).  I think you'd have to poke pg_database.datcollate
 and datctype directly as a superuser for this to happen, but AFAIR
 there's not any underlying magic that would prevent it from working.

 3. Drop all the now-useless indexes with the old collation.

 One fly in the ointment is that step 1 would result in indexes marked
 with indcollate equal to the explicitly chosen collation.  There was
 just some discussion the other day about how the planner wouldn't
 recognize that this is equivalent to COLLATE "default", so after 2
 you might also need a step that runs through pg_index and updates
 the collation OIDs to match the "default" collation.

 Obviously, this is untested and you'd be foolish not to try it out
 on a test installation before believing that it works.  But I think
 it might, and if you are looking at a seriously painful dump+reload
 it'd be worth the trouble to debug a process for it.

 regards, tom lane

Thanks for the explanation, I'll try it out!

What about ORDER BY on columns without an index, would they sort correctly?

-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andr...@visena.com 
www.visena.com

Re: [GENERAL] WIP: CoC V5


On 01/12/2016 02:43 PM, Kevin Grittner wrote:

I think that this is fairly close to something that would make
sense, but there is sort of a weirdness in the CoC referring to
itself in the 3rd person.  It sound more like an argument for
*having* a CoC than the document itself.

I'm not the greatest word-smith, but I'll attempt to rework Josh's
draft to something that seems more "natural" to me.  At the same
time, I'll try to incorporate other comments, like Tom's comment
about enforcement mechanisms and the gray areas in members of the
community communicating in public forums.


On Tom's comment, I was waiting until we have a firmed up version. On 
the communicating in public forums, I must have missed that, do you have 
a reference?


What isn't shown here, is that I was writing in a similar fashion that 
you would write a resolution for a NP. Consider (very rough):


WHEREAS

The PostgreSQL Global Development Group (PGDG) would like to insure a 
safe, respectful, productive and collaborative environment for all.


PGDG Resolves that

1. There shall be a Code of Conduct governing behaviour for the PGDG 
community.


2. The CoC is to provide community guidelines for creating and enforcing 
a safe, respectful, productive, and collaborative place for any person 
who is willing to contribute in a safe, respectful, productive and 
collaborative way.


3. The CoC is not about being offended. As with any diverse community, 
anyone can get offended at anything.


4. A safe, respectful, productive and collaborative environment is free 
of personal attacks and disparaging remarks of any kind.


5. Any sustained disruption of the collaborative space (mailing lists, 
IRC etc..) or other PostgreSQL events shall be construed as a violation 
of the CoC and appropriate action will be taken by the CoC committee.


6. The CoC is only about interaction with the PostgreSQL community. Your 
private and public lives outside of the PostgreSQL community are your own.




--
Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Moving a large DB (> 500GB) to another DB with different locale

Andreas Joseph Krogh  writes:
> What about ORDER BY on columns without an index, would they sort correctly?

Sorting is sorting, it'll just use whatever collation is specified or
implied.

regards, tom lane


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Moving a large DB (> 500GB) to another DB with different locale

På onsdag 13. januar 2016 kl. 00:03:18, skrev Tom Lane >:
Andreas Joseph Krogh  writes:
 > What about ORDER BY on columns without an index, would they sort correctly?

 Sorting is sorting, it'll just use whatever collation is specified or
 implied.

 regards, tom lane
 
Right, so poking with pg_database.datcollate would take care of that so no 
explicit COLLATE has to be issued on ORDER BY?
 
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andr...@visena.com 
www.visena.com

Re: [GENERAL] WIP: CoC V5

2016-01-12 Thread Kevin Grittner

I think that this is fairly close to something that would make
sense, but there is sort of a weirdness in the CoC referring to
itself in the 3rd person.  It sound more like an argument for
*having* a CoC than the document itself.

I'm not the greatest word-smith, but I'll attempt to rework Josh's
draft to something that seems more "natural" to me.  At the same
time, I'll try to incorporate other comments, like Tom's comment
about enforcement mechanisms and the gray areas in members of the
community communicating in public forums.

On Tue, Jan 12, 2016 at 3:37 PM, Joshua D. Drake  wrote:

> PostgreSQL Global Development Group (PGDG) Code of Conduct (CoC):
>
> 1. The CoC is to provide community guidelines for creating and enforcing a
> safe, respectful, productive, and collaborative place for any person who is
> willing to contribute in a safe, respectful, productive and collaborative
> way.
>
> 2. A safe, respectful, productive and collaborative environment is free of
> personal attacks and disparaging remarks of any kind.
>
> 3. The CoC is not about being offended. One should always assume good
> intentions. As with any diverse community, anyone can get offended at
> anything.
>
> 4. Any sustained disruption of the collaborative space (mailing lists, IRC
> etc..) or other PostgreSQL events shall be construed as a violation of the
> CoC and appropriate action will be taken by the CoC committee.
>
> 5. The CoC is only about interaction with the PostgreSQL community. Your
> private and public lives outside of the PostgreSQL community are your own.

== PostgreSQL Community Code of Conduct (CoC) ==

This document is intended to provide community guidelines for
creating and enforcing a safe, respectful, productive, and
collaborative place for any person who is willing to contribute in
a safe, respectful, productive and collaborative way.

* To maintain a safe, respectful, productive and collaborative
environment all participants must ensure that their language and
actions are free of personal attacks and disparaging remarks of any
kind.

* When interpreting the words and actions of others, participants
should always assume good intentions.  Consider that due to
language and cultural differences, something may be intended in a
benign or helpful way, even if some participants initially see a
possible interpretation which is otherwise.

* All participants must avoid sustained disruption of the
collaborative space (mailing lists, IRC etc..) or other PostgreSQL
events.

* There is a distinction between words and actions taken inside the
community and words and actions outside community communication
channels and events, but there is a gray area when using public
forums or social media where a person identifies as a member of
this community.  Members of the community, especially those with a
high profile within the community, should be mindful of this and
avoid anything which might create an unwelcoming or hostile
attitude toward the community in such venues.

* Participants who feel that they have not been treated in
accordance with this Code of Conduct may want to try to sort things
out in the forum where there was a perception of a problem; asking
for a clarification or an apology either in a public discussion
context or privately can often resolve an issue quickly to
everyone's satisfaction.  Where this fails, the Core Team is
responsible for determining what, if any, action is appropriate.
The core team is listed, with a link to the purpose of team, at the
top of the community's "Contributor Profiles" page:
http://www.postgresql.org/community/contributors/

To me, this reads more like the document itself.  I hope I have
done justice to Josh's points as well as Tom's, although I would
bet there are a number of people on the list that can improve on my
effort here.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] WIP: CoC V5


On 01/12/2016 02:43 PM, Kevin Grittner wrote:

I guess I should scroll all the way down. :P




To me, this reads more like the document itself.  I hope I have
done justice to Josh's points as well as Tom's, although I would
bet there are a number of people on the list that can improve on my
effort here.


I read your whole document. It is not badly written and I would agree it 
does read a bit more like a lot of the CoCs out there. My critique would 
be that it adds words for the sake of adding words. The more words the 
more ambiguity and the more nits to pick.


As we have all appeared to coalesce around v5, I would suggest that we 
stick with it or gently modify v5 up to the point that it is something 
that sticks.


Sincerely,

JD


--
Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Text parameter is treated as sql query in postgresql function

2016-01-12 Thread Yash Gajbhiye

Hello Adrian,

Thank you for your response. Sorry about the typos in the previous post.

I will try to explain myself more clearly.

This is my first function to create a dynamic query and it is as follows:

CREATE OR REPLACE FUNCTION dynamic_crosstab(
source_sql text,
category_sql text,
v_matrix_col_type text,
v_matrix_rows_name_and_type text,
debug boolean DEFAULT false)
  RETURNS text AS
$BODY$
DECLARE
v_sql text;
curs1 refcursor;
v_val text;
BEGIN
v_sql = v_matrix_rows_name_and_type;
OPEN curs1 FOR execute category_sql;
Loop
FETCH curs1 INTO v_val;
exit when v_val IS NULL;
v_sql = v_sql ||' , "'||v_val||'" '||v_matrix_col_type;
IF debug THEN
RAISE NOTICE 'v_val = %',v_val;
END IF;
END LOOP;
CLOSE curs1;
v_sql := 'SELECT * from crosstab(' || chr(10) || E' \''||source_sql ||
E'\','||chr(10) || E' \''||category_sql || E'\'' || chr(10)|| ' ) AS (' ||
v_sql ||')';
IF debug THEN
RAISE NOTICE 'v_sql = %',v_sql;
END IF;
RETURN v_sql;
END;

This works fine. It accepts 2 sql queries and other parameters as inputs
and output is a sql query which looks like this:

SELECT * from crosstab( sql query 1, sql query 2) AS ();

and this query works fine too.

I want to execute and return rows from this query. Hence I am using another
function to accomplish, which is :

CREATE OR REPLACE FUNCTION leavetypeaccrual(
cur refcursor,
text,
text,
text)
  RETURNS SETOF refcursor AS
$BODY$
declare
val_1 text;
begin
select * from dynamic_crosstab( 'select
p.location_id, p.employee_id, pt.description, sum(p.hours_allocated) as
hours_allocated
from
preference_type pt, preference p, preference_date_etl pde, date_etl de
where
pt.id = p.preference_type_id and
pde.preference_id = p.id and
pde.corporation_id = $4 and
de.id = pde.date_etl_id and
pde.deleted = N and
p.deleted = N and
pt.deleted = N and
de.local_date between $2 and $3 and
p.employee_id IN (
select id from employee where user_id IN ( select id from app_user where
corporation_id =$4))
group by p.location_id, p.employee_id, pt.description ',
' select distinct description from preference_type where deleted =N
and corporation_id=' || $4,
'text','location_id int , employee_id int',false)  into val_1;
open cur for execute val_1;
return next cur;
end;

Now the first input parameter for my select * from dynamic_crosstab(...) is
treated as a string input , but the second input parameter (' select
distinct description from preference_type.) is treated as a seperate
sql query instead of string because of the N. I need to use
deleted='N the same way I have used in first input parameter.
Please advice how I can achieve this.

Error Message:

ERROR:  syntax error at or near "N"
LINE 1: ...description from preference_type where deleted =''N'' and co...
 ^
QUERY:   select distinct description from preference_type where deleted
=''N'' and corporation_id=43340
CONTEXT:  PL/pgSQL function dynamic_crosstab(text,text,text,text,boolean)
line 8 at OPEN
SQL statement "select * from dynamic_crosstab(' select
p.location_id, p.employee_id, pt.description, sum(p.hours_allocated) as
hours_allocated
from
preference_type pt, preference p, preference_date_etl pde, date_etl de
where
pt.id = p.preference_type_id and
pde.preference_id = p.id and
pde.corporation_id = $4 and
de.id = pde.date_etl_id and
pde.deleted = N and
p.deleted = N and
pt.deleted = N and
de.local_date between $2 and $3 and
p.employee_id IN (
select id from employee where user_id IN ( select id from app_user where
corporation_id =$4))
group by p.location_id, p.employee_id, pt.description ',
' select distinct description from preference_type where deleted =N
and corporation_id=' || $4,
'text','location_id int , employee_id int',false)"
PL/pgSQL function leavetypeaccrual(refcursor,text,text,text) line 5 at SQL
statement

Thanks
Yash.

On Tue, Jan 12, 2016 at 9:44 AM, Adrian Klaver 
wrote:

> On 01/11/2016 11:47 PM, Yash Gajbhiye wrote:
>
>> I am using postgres crosstab() function to create a table.
>>
>> My first dynamic query function (dynamic_crosstab) creates a sql select
>> statement containing crosstab(), and then this select statement gives
>> the final result on execution. /*dynamic_crosstab functions works
>> perfectly*/
>>
>> I need to execute this select query (result of dynamic_crosstab
>> function) by using parameters, so I am again using a function as follows.
>>
>>
>> CREATE OR REPLACE FUNCTION leavetypeaccrual(
>>
>> cur refcursor,
>>
>>  text,
>>
>>  text,
>>
>>  text)
>>
>>RETURNS SETOF refcursor AS
>>
>> $BODY$
>>
>> declare
>>
>> val_1 text;
>>
>> begin
>>
>> select * from dynamic_crosstab($ select
>>
>> p.location_id, p.employee_id, pt.description, sum(p.hours_allocated) as
>> hours_allocated
>>
>
> I am having a hard figuring out what the above is supposed to

Re: [GENERAL] Text parameter is treated as sql query in postgresql function

2016-01-12 Thread Raymond O'Donnell

On 12/01/2016 17:07, Yash Gajbhiye wrote:
> Hello Adrian,
> 
> Thank you for your response. Sorry about the typos in the previous post.
> 
> I will try to explain myself more clearly. 
> 
> This is my first function to create a dynamic query and it is as follows:
> 
> CREATE OR REPLACE FUNCTION dynamic_crosstab(
> source_sql text,
> category_sql text,
> v_matrix_col_type text,
> v_matrix_rows_name_and_type text,
> debug boolean DEFAULT false)
>   RETURNS text AS
> $BODY$
> DECLARE
> v_sql text;
> curs1 refcursor;
> v_val text;
> BEGIN
> v_sql = v_matrix_rows_name_and_type;
> OPEN curs1 FOR execute category_sql;
> Loop
> FETCH curs1 INTO v_val;
> exit when v_val IS NULL;
> v_sql = v_sql ||' , "'||v_val||'" '||v_matrix_col_type;
> IF debug THEN
> RAISE NOTICE 'v_val = %',v_val;
> END IF; 
> END LOOP;
> CLOSE curs1;
> v_sql := 'SELECT * from crosstab(' || chr(10) || E' \''||source_sql ||
> E'\','||chr(10) || E' \''||category_sql || E'\'' || chr(10)|| ' ) AS ('
> || v_sql ||')';
> IF debug THEN
> RAISE NOTICE 'v_sql = %',v_sql;
> END IF;
> RETURN v_sql;
> END;
> 
> This works fine. It accepts 2 sql queries and other parameters as inputs
> and output is a sql query which looks like this:
> 
> SELECT * from crosstab( sql query 1, sql query 2) AS ();
> 
> and this query works fine too.
> 
> I want to execute and return rows from this query. Hence I am using
> another function to accomplish, which is :
> 
> CREATE OR REPLACE FUNCTION leavetypeaccrual(
> cur refcursor,
> text,
> text,
> text)
>   RETURNS SETOF refcursor AS
> $BODY$
> declare
> val_1 text;
> begin
> select * from dynamic_crosstab( 'select 
> p.location_id, p.employee_id, pt.description, sum(p.hours_allocated) as
> hours_allocated
> from
> preference_type pt, preference p, preference_date_etl pde, date_etl de
> where
> pt.id  = p.preference_type_id and
> pde.preference_id = p.id  and
> pde.corporation_id = $4 and
> de.id  = pde.date_etl_id and
> pde.deleted = N and
> p.deleted = N and
> pt.deleted = N and
> de.local_date between $2 and $3 and

I missed whatever passed upthread, but at a guess I'd say all the
quoting is causing problems here. Why not use the quote_ident() and
quote_literal() functions? By the same token, I don't think you need to
put quotation marks around the parameters.

Ray.



-- 
Raymond O'Donnell :: Galway :: Ireland
r...@iol.ie


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] WIP: CoC V4


Tl;dr;

* Removed specific examples and reworded #3 to be more concise

PostgreSQL Global Development Group (PGDG) Code of Conduct (CoC):

1. The CoC is to provide community guidelines for creating and enforcing 
a safe, respectful, productive, and collaborative place for any person 
who is willing to contribute in a safe, respectful, productive and 
collaborative way.


2. The CoC is not about being offended. As with any diverse community, 
anyone can get offended at anything.


3. A safe, respectful, productive and collaborative environment is free 
of personal attacks and disparaging remarks of any kind.


4. Any sustained disruption of the collaborative space (mailing lists, 
IRC etc..) or other PostgreSQL events shall be construed as a violation 
of the CoC and appropriate action will be taken by the CoC committee.


5. The CoC is only about interaction with the PostgreSQL community. Your 
private and public lives outside of the PostgreSQL community are your own.


--
Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] WIP: CoC

2016-01-12 Thread Neil Tiffin


> On Jan 12, 2016, at 12:20 AM, Tom Lane  wrote:
> 
> [ just a few comments on specific points ]
> 
> "Greg Sabino Mullane"  writes:
>>> 2. The CoC is not about being offended. The act of being offended is 
>>> purely a recipient response and usually the offended individual is more 
>>> interested in being a victim than moving forward.
> 
>> Too defensive; not needed in the code of conduct.
> 
> Agreed, let's avoid defensiveness here.  There's not much advantage to
> this whole exercise unless we can be welcoming rather than dismissive.
> 

How about a simple statement?

2. We expect people to be both tolerant and respectful of others.

Neil



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Text parameter is treated as sql query in postgresql function