On Mon, Sep 15, 2014 at 5:39 AM, Kevin Grittner wrote:
> Abelard Hoffman wrote:
>
> >> Boolean values can be written as on, off, true, false, yes, no,
> >> 1, 0 (all case-insensitive) or any unambiguous prefix of these.
> >
> > is there a built-in function I can call, given the value from
> > cu
rummandba wrote
> Hi,
>
> I am trying to use pgcluu with collected stats and got the error:
> Can't call method "print" on an undefined value at
> /opt/pgdata/pgcluu_prod/pgcluubin/pgcluu line 5494
>
> Any one has idea?
>
> Thanks.
You should at least mention that you, correctly, opened an issu
cowwoc wrote
> On 15/09/2014 2:02 PM, lup [via PostgreSQL] wrote:
>> On 09/15/2014 11:49 AM, cowwoc wrote:
>>> I think developers choosing this route (myself included) are willing
>>> to pay the price in exchange for improved readability/maintainability
>>> (the assumption being that the resultin
Hi,
I am trying to use pgcluu with collected stats and got the error:
Can't call method "print" on an undefined value at
/opt/pgdata/pgcluu_prod/pgcluubin/pgcluu line 5494
Any one has idea?
Thanks.
On 15/09/2014 3:50 PM, Thomas Kellerer [via PostgreSQL] wrote:
> cowwoc wrote on 15.09.2014 19:55:
> > H2, HSQLDB, Derby all support Java triggers.
>
> But only because they already live/run inside a JVM, so it's the
> "natural" choice of language.
>
> And H2 and Derby *only* support Java stored p
## p...@mailme.dk (p...@mailme.dk):
> Is it already possible or would you consider a configuration option that
> would only replicate DML but not DDL ?
bdr.skip_ddl_replication = true
can even be set at transaction level
Regards,
Christoph
--
Spare Space
--
Sent via pgsql-general mailing li
cowwoc wrote on 15.09.2014 19:55:
H2, HSQLDB, Derby all support Java triggers.
But only because they already live/run inside a JVM, so it's the "natural"
choice of language.
And H2 and Derby *only* support Java stored procedures.
The main disadvantage I see with that is, that you can't "just
On Mon, 15 Sep 2014 13:34:53 -0400
cowwoc wrote:
> > 2. What is your specific use case for a trigger in Java?
>
> The main drivers are:
>
> 1. Not having to learn yet another language.
Bear in mind that DB programmers often know SQL. To me, and apparently to them,
PL/pgsql seems closer to th
On 15 September 2014 20:13, cowwoc wrote:
On 15/09/2014 2:12 PM, cowwoc wrote:
>
> On 15/09/2014 2:02 PM, lup [via PostgreSQL] wrote:
>
> On 09/15/2014 11:49 AM, cowwoc wrote:
>
> I think developers choosing this route (myself included) are willing to
> pay the price in exchange for improved read
On 09/15/2014 11:00 AM, Rob Sargent wrote:
On 09/15/2014 11:49 AM, cowwoc wrote:
Hi Pavel,
On 15/09/2014 1:40 PM, Pavel Stehule wrote:
The main drivers are:
1. Not having to learn yet another language. I find the
expressiveness and readability of the other scripting
langu
On 15/09/2014 2:12 PM, cowwoc wrote:
> On 15/09/2014 2:02 PM, lup [via PostgreSQL] wrote:
>> On 09/15/2014 11:49 AM, cowwoc wrote:
>>> I think developers choosing this route (myself included) are willing
>>> to pay the price in exchange for improved
>>> readability/maintainability (the assumption
On 15/09/2014 2:02 PM, lup [via PostgreSQL] wrote:
> On 09/15/2014 11:49 AM, cowwoc wrote:
>> I think developers choosing this route (myself included) are willing
>> to pay the price in exchange for improved readability/maintainability
>> (the assumption being that the resulting performance will
2014-09-15 19:49 GMT+02:00 cowwoc :
> Hi Pavel,
>
> On 15/09/2014 1:40 PM, Pavel Stehule wrote:
>
> The main drivers are:
>
>>
>>1. Not having to learn yet another language. I find the
>>expressiveness and readability of the other scripting languages very
>> clunky
>>compared to Java
On 15/09/2014 1:51 PM, Pavel Stehule [via PostgreSQL] wrote:
> and I am not sure if Java as stored procedures is living technology,
> It was designed as "esperanto", but it is supported only by Oracle
> after 14 years.
>
> Pavel
H2, HSQLDB, Derby all support Java triggers. Granted, we are not ta
Is it already possible or would you consider a configuration option that
would only replicate DML but not DDL ?
This should of course be combined with a predictable way of manually
handling DDL errors. Like simply manually adding any missing DDL on the
"slave".
Thanks
Poul
--
Sent via pgsql-
On 09/15/2014 11:49 AM, cowwoc wrote:
Hi Pavel,
On 15/09/2014 1:40 PM, Pavel Stehule wrote:
The main drivers are:
1. Not having to learn yet another language. I find the
expressiveness and readability of the other scripting
languages very clunky compared to Java.
PLpgSQL
Ubuntu 14.04 with compiled BDR 0.7.1
This is a very interesting project for a lot of potential applications.
However as in any project there will be a few initial issues.
My question is how do I recover from DDL errors ?
For example: given a setup of 2 BDR PostgreSQL hosts and on one of them
exe
On 09/15/2014 08:05 AM, cowwoc wrote:
On 15/09/2014 10:37 AM, Adrian Klaver wrote:
From your second post:
" 1. I'm already planning to run unit tests against a separate (but
identical) database than production, so there's no danger of wiping
out the production database.
2. I need to cr
2014-09-15 19:46 GMT+02:00 Pavel Stehule :
>
>
> 2014-09-15 19:37 GMT+02:00 cowwoc :
>
>> On 15/09/2014 7:58 AM, Bill Moran wrote:
>>
>>> On Sun, 14 Sep 2014 22:22:21 -0700 (PDT)
>>> cowwoc wrote:
>>>
Out of curiosity, why is Postgresql's Java support so poor?
>>> To trampoline off what
Hi Pavel,
On 15/09/2014 1:40 PM, Pavel Stehule wrote:
The main drivers are:
1. Not having to learn yet another language. I find the
expressiveness and readability of the other scripting
languages very clunky compared to Java.
PLpgSQL is different, it is based on Ada langu
2014-09-15 19:37 GMT+02:00 cowwoc :
> On 15/09/2014 7:58 AM, Bill Moran wrote:
>
>> On Sun, 14 Sep 2014 22:22:21 -0700 (PDT)
>> cowwoc wrote:
>>
>>> Out of curiosity, why is Postgresql's Java support so poor?
>>>
>> To trampoline off what others have said: it gets implemented and
>> maintained if
Problem has been solved utilizing tcpdump which revealed that the standbys were
not trying to contact the primary server, although they each were contacting
the other standby. From
this, we determined that a minor typographical error was present in the
pgpool.conf file. The setting under the wa
2014-09-15 19:34 GMT+02:00 cowwoc :
> On 15/09/2014 7:03 AM, Chris Travers wrote:
>
> I have a few questions on this, the answers of which may help answer your
> question:
>
> 1. How well does having a server-side JVM work, resource-wise, when you
> have a forked process model like PostgreSQL?
On 15/09/2014 7:58 AM, Bill Moran wrote:
On Sun, 14 Sep 2014 22:22:21 -0700 (PDT)
cowwoc wrote:
Out of curiosity, why is Postgresql's Java support so poor?
To trampoline off what others have said: it gets implemented and maintained if
people want/need it.
But I feel like I have a little more
On 15/09/2014 7:03 AM, Chris Travers wrote:
I have a few questions on this, the answers of which may help answer
your question:
1. How well does having a server-side JVM work, resource-wise, when
you have a forked process model like PostgreSQL? Does having the
additional JVM's pose performa
Hi guys,
Any chance you guys could help cleaning up the build/deploy process?
This is a pretty big hurdle to overcome for new users.
Gili
On 15/09/2014 8:55 AM, Tim Clarke [via PostgreSQL] wrote:
> On 15/09/14 13:30, Achilleas Mantzios wrote:
>
> >
> > This is far from dead. I works perfectly w
On Tue, Sep 16, 2014 at 1:43 AM, Michael Paquier
wrote:
> https://apps.fedoraproject.org/packages/v8
Forgot to add that this is probably one of the reasons why Fedora
sticks to this version.
--
Michael
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to you
On Mon, Sep 15, 2014 at 11:23 PM, Merlin Moncure wrote:
> So I'd argue plv8 has a much better case of being put 'in core', but
> I'd argue that neither of them should be. Why? The core team is
> already supporting enough code and it seems better to make the
> extension framework more robust so th
On 15/09/2014 10:37 AM, Adrian Klaver wrote:
From your second post:
" 1. I'm already planning to run unit tests against a separate (but
identical) database than production, so there's no danger of wiping
out the production database.
2. I need to create a new temporary schema per test, a
On 09/15/2014 07:08 AM, cowwoc wrote:
On 15/09/2014 9:39 AM, Adrian Klaver wrote:
Not exactly. Each test is responsible for populating its own schema
(creating tables, inserting data). The main purpose of using temporary
schemas is to ensure that each test runs in isolation so that data from
ot
Interesting enough concept. Please don't forget to test against a realistic
data set as well. It does seem to me that the devs can easily make, fill, clean
up their own db. And a central builder (eg Jenkins?) can do the same with,
importantly using ALL tests.
Then again using real data.
> On
On Mon, Sep 15, 2014 at 6:03 AM, Chris Travers wrote:
>
>
> On Sun, Sep 14, 2014 at 10:22 PM, cowwoc wrote:
>>
>> Hi,
>>
>> Out of curiosity, why is Postgresql's Java support so poor? I am
>> specifically looking for the ability to write triggers in Java.
>
>
> Because it hasn't been a priority o
On 15/09/2014 9:39 AM, Adrian Klaver wrote:
Not exactly. Each test is responsible for populating its own schema
(creating tables, inserting data). The main purpose of using temporary
schemas is to ensure that each test runs in isolation so that data from
other tests cannot influence the outcome
On 09/14/2014 08:21 PM, cowwoc wrote:
Hi Adrian,
Replies below.
On 14/09/2014 8:34 PM, Adrian Klaver wrote:
On 09/14/2014 02:01 PM, cowwoc wrote:
See http://dba.stackexchange.com/q/76494/4719 for a related discussion.
So from the above link and the discussion here so far I gather you want:
On 15/09/14 13:30, Achilleas Mantzios wrote:
>
> This is far from dead. I works perfectly with java 1.7 and postgresql
> 9.3 ,
> but you need maybe a little bit more extra homework + some skills with
> maven.
> If i managed to build this on a FreeBSD machine, in linux it should a
> piece of cake.
>
Abelard Hoffman wrote:
>> Boolean values can be written as on, off, true, false, yes, no,
>> 1, 0 (all case-insensitive) or any unambiguous prefix of these.
>
> is there a built-in function I can call, given the value from
> current_setting('myapp.audit'), that will test it using the same
> logic
On 15/09/2014 08:22, cowwoc wrote:
Hi,
Out of curiosity, why is Postgresql's Java support so poor? I am
specifically looking for the ability to write triggers in Java.
I took a look at the PL/Java project and it looked both incomplete and dead,
yet other languages like Javascript are taking off
On 9/15/14, Chris Travers wrote:
> On Sun, Sep 14, 2014 at 10:22 PM, cowwoc wrote:
>> Out of curiosity, why is Postgresql's Java support so poor? I am
>> specifically looking for the ability to write triggers in Java.
>
> Because it hasn't been a priority of contributors. This is how
> non-singl
Hi all,
has anyone maybe test sp-gist over ltree datatype?
would sp-gist be better option for it?
Thanks,
Misa
On Sun, 14 Sep 2014 22:22:21 -0700 (PDT)
cowwoc wrote:
>
> Out of curiosity, why is Postgresql's Java support so poor?
To trampoline off what others have said: it gets implemented and maintained if
people want/need it.
But I feel like I have a little more insight into _why_ people aren't taking
On Sun, Sep 14, 2014 at 10:22 PM, cowwoc wrote:
> Hi,
>
> Out of curiosity, why is Postgresql's Java support so poor? I am
> specifically looking for the ability to write triggers in Java.
>
Because it hasn't been a priority of contributors. This is how
non-single-vendor open source projects wo
On Mon, Sep 15, 2014 at 8:22 AM, cowwoc wrote:
> I took a look at the PL/Java project and it looked both incomplete and dead,
> yet other languages like Javascript are taking off. I would have expected to
> see very strong support for Java because it's the most frequently used
> language on the se
42 matches
Mail list logo
