Thanks for the link. After looking through it i see following major points:
- thread is from 2013 and nothing changed today in 2016
- quote from that thread (C) Dimitri Fontaine
"That topic apparently raises each year and rehash the same points"
(So ... there should be more similar discussio
If all you want is a temporary function, you *can* create it in the pg_temp
namespace though that seems hackish.
Maybe a better solution would be to extend CREATE FUNCTION in a way that
allows you to CREATE TEMPORARY FUNCTION?
On Sun, Aug 14, 2016 at 9:28 AM, Xtra Coder wrote:
> Thanks for the
Thanks, I'm aware about ability to create temp functions, but this is
actually too much overhead - I mean unneeded boilerplate code, but it seems
in current state it is "the least evil" which I have to use.
I think 'what i need' is support for following
- ability to switch session language from 's
On Fri, Aug 12, 2016 at 01:32:33PM +0200, Chris Travers wrote:
>>> My preference is stored procedures plus service locators
>>
>> Would you care to elaborate a little on the latter (service locators) ?
>>
>
> Sure. What I prefer to do is to allow for a (cacheable) lookup on the
> basis of some c
On Sun, Aug 14, 2016 at 12:35 PM, Karsten Hilbert
wrote:
> On Fri, Aug 12, 2016 at 01:32:33PM +0200, Chris Travers wrote:
>
> >>> My preference is stored procedures plus service locators
> >>
> >> Would you care to elaborate a little on the latter (service locators) ?
> >>
> >
> > Sure. What I p
On Sun, Aug 14, 2016 at 12:13 PM, Xtra Coder wrote:
> Thanks, I'm aware about ability to create temp functions, but this is
> actually too much overhead - I mean unneeded boilerplate code, but it seems
> in current state it is "the least evil" which I have to use.
>
> I think 'what i need' is sup
Hello Chris,
I am getting closer but ...
> > > Sure. What I prefer to do is to allow for a (cacheable) lookup on the
> > > basis of some criteria, either:
> > > 1. Function name or
> > > 2. Function name and first argument type
> > >
> > > This assumes that whichever discovery criteria you are
On Sun, Aug 14, 2016 at 3:42 PM, Karsten Hilbert
wrote:
> Hello Chris,
>
> I am getting closer but ...
>
> > > > Sure. What I prefer to do is to allow for a (cacheable) lookup on
> the
> > > > basis of some criteria, either:
> > > > 1. Function name or
> > > > 2. Function name and first argume
On Sun, Aug 14, 2016 at 04:02:19PM +0200, Chris Travers wrote:
> One example is of such a service locator is
> http://search.cpan.org/dist/PGObject-Simple/lib/PGObject/Simple.pm
>
> It runs as a library which helps the program decide how to do the call.
> Currently it looks in the system catalog
Hi folks --
We have ported Postgres over to the C++ language (C++11 standard).
https://github.com/jarulraj/postgresql-cpp
Our goal is to use certain features of the C++ language and its standard
library to simplify coding, improve code reuse, and avoid bugs. Peter's
article titled `Moving to C++
On 8/14/2016 2:05 PM, Joy Arulraj wrote:
We have ported Postgres over to the C++ language (C++11 standard).
https://github.com/jarulraj/postgresql-cpp
Our goal is to use certain features of the C++ language and its
standard library to simplify coding, improve code reuse, and avoid
bugs. Pete
Hi Joy,
2016-08-15 0:05 GMT+03:00 Joy Arulraj :
> Hi folks --
>
> We have ported Postgres over to the C++ language (C++11 standard).
>
> https://github.com/jarulraj/postgresql-cpp
>
> Our goal is to use certain features of the C++ language and its standard
> library to simplify coding, improve cod
Hi Dmitry -- We currently don't use exceptions, but we can certainly use
them in the port. We can also use STL and smart pointers to simplify
development and minimize memory bugs.
On Aug 14, 2016 5:41 PM, "Dmitry Igrishin" wrote:
> Hi Joy,
>
> 2016-08-15 0:05 GMT+03:00 Joy Arulraj :
> > Hi folks
I agree with this project, I dont like any setjmp/longjmp and the
like. It just fighting against the nature of c++ language. Building
either from scratch gcc48 or clang381 were easy nowdays on either old
linux debian squeeze or centos 5. PS: I had this requirement
circumtances.
On 8/15/16, Joy Aru
Kang -- Yes, this is one of the reasons why we chose to do this.
John -- We have not compiled it with non-GCC compilers. But, I presume that
the changes required to support compilation with other compilers should be
minimal as we don't rely on any compiler-specific features.
On Sun, Aug 14, 2016
Hello All,
The thing which I find a little worrying is that this 'corruption' was
introduced either on the network from PROD -> DR, but then also cascaded to
both other DR servers (either via replication or via archive_command).
Is WAL corruption checked for in any way on standby servers?.
Here
Hi,
We are using PostgreSQL 9.3.11. We are observing DB update failed due to
lock timeout. failure because waiting for RowExclusiveLock. Autovacuum uses
plain vacuum which uses ShareUpdateExclusiveLock. right?
But from Postgres Manual chapter 13.3. Explicit Locking. both Locks has no
conflict. S
On Mon, Aug 15, 2016 at 12:34 PM zh1029 wrote:
> Hi,
> We are using PostgreSQL 9.3.11. We are observing DB update failed due to
> lock timeout. failure because waiting for RowExclusiveLock. Autovacuum
> uses
> plain vacuum which uses ShareUpdateExclusiveLock. right?
>
This I learnt recently,
18 matches
Mail list logo
