Well, it's the end of March, and I'm already starting to feel like we've
been commit-festing forever :-(. At this point I see only one remaining
patch that seems likely to go in without any further discussion --- that's
Pavel's plpgsql EXECUTE USING thing. However, we've got boatloads of
stuff th
I wrote:
> [EMAIL PROTECTED] writes:
>> The only diff is that jaguar is compiling with -DCLOBBER_CACHE_ALWAYS
>> Is that related?
> Hmm, that might be the needed clue --- thanks for the reminder.
Yup, that was it --- was able to duplicate the problem with
-DCLOBBER_CACHE_ALWAYS. So I think jagua
Hey Jonah,
You are correct. I have worked with oracle for a long time and only recently
started working with Postgres. I am quite satisfied that Postgres is able to
deliver me most of the features/ services which Oracle used to deliver but at
much reduced cost.This is very helpful in pushing
Kevin Hunter <[EMAIL PROTECTED]> writes:
> At 3:50p -0400 on Sat, 29 Mar 2008, Tom Lane wrote:
>> The code appears to want 700 and ownership equal to that of the
>> process executing libpq, ie, the apache server.
> I just checked the 8.3 documentation and didn't see any mention of
> the private ke
On Sun, Mar 30, 2008 at 2:52 PM, sanjay sharma <[EMAIL PROTECTED]> wrote:
> 1. Transparent Data Encryption: The column which needs to be stored in
> encrypted form can be specified through DDL.
Hey Sanjay. Based on your wording, you've probably used Oracle's TDE
and want to implement it in PG.
On Sun, Mar 30, 2008 at 4:36 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> sanjay sharma <[EMAIL PROTECTED]> writes:
> > 1. Transparent Data Encryption: The column which needs to be stored in
> encrypted form can be specified through DDL. The encryption key can be stored
> in a secure file accessib
Joris Dobbelsteen <[EMAIL PROTECTED]> writes:
> The MAJOR benefit of Microsoft's approach is that it works on existing
> application, and, most importantly makes NO assumptions on the
> "volatile" server state. A few cases where the Microsoft solution works,
> while yours will fail is:
> *
PFC <[EMAIL PROTECTED]> writes:
> Here is the result of my little experiment, for your viewing pleasure,
I'm having a problem with the terminology here, since AFAICT what your
patch does is exactly not a global "prepare" --- there is no permanently
stored cached plan. That's a good thing pr
sanjay sharma <[EMAIL PROTECTED]> writes:
> 1. Transparent Data Encryption: The column which needs to be stored in
> encrypted form can be specified through DDL. The encryption key can be stored
> in a secure file accessible through a pass phrase. That particular column
> would apper in encrypt
On Sun, Mar 30, 2008 at 10:00:33PM +0200, Pavel Stehule wrote:
> Hello
>
> maybe I don't understand well your idea. There exist simple syntax -
> table function
>
> http://archives.postgresql.org/pgsql-patches/2007-02/msg00341.php
>
> and it is standard
It's completely different from your patch
Hello
maybe I don't understand well your idea. There exist simple syntax -
table function
http://archives.postgresql.org/pgsql-patches/2007-02/msg00341.php
and it is standard
regards
Pavel Stehule
On 30/03/2008, David Fetter <[EMAIL PROTECTED]> wrote:
> Folks,
>
> I'd like to take a whack at
[EMAIL PROTECTED] writes:
> As you can see here:
> http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=jaguar&br=HEAD
> Jaguar has been failing for two days while centaur is ok.
I asked you to look into that yesterday
http://archives.postgresql.org/pgsql-hackers/2008-03/msg01216.php
The copy of
PFC wrote:
PFC wrote:
Hello,
So, I embarked (yesterday) on a weekend project to add a new
feature to Postgres...
I use PHP with persistent connections and always have been
bothered that those very small AJAX queries (usually simple selects
returning 1 row) take more CPU in postgre
"Sibte Abbas" <[EMAIL PROTECTED]> writes:
> On 9/9/07, Sibte Abbas <[EMAIL PROTECTED]> wrote:
>> Attached is the patch for the TODO item mentioned at
>> http://archives.postgresql.org/pgsql-hackers/2007-09/msg00352.php
I looked this over and realized that it has little to do with the
functionality
Hello All,
I would like to submit following feature request for Postgres:
1. Transparent Data Encryption: The column which needs to be stored in
encrypted form can be specified through DDL. The encryption key can be stored
in a secure file accessible through a pass phrase. That particular c
Folks,
I'd like to take a whack at making set-returning functions returning
SETOF RECORD a little more fun to use. Let's imagine that we have a
table foo and a function returning SETOF RECORD that can return foos.
The call might look something like:
SELECT a, b, c
FROM f(ROW OF foo)
WHERE ...;
Andrew Gilligan <[EMAIL PROTECTED]> writes:
> I've attached an updated patch (based on 8.3RC2) that adds the ACL
> information to \l and the size to \l+ if available.
Applied, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Here is the result of my little experiment, for your viewing pleasure,
lol.
Now it works. Well, it hasn't crashed yet... so I guess I can show it to
people ;)
- Purpose :
Allow PHP (or other languages) users to use prepared statements
(pg_exec()) together with persistent connections, w
As you can see here:
http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=jaguar&br=HEAD
Jaguar has been failing for two days while centaur is ok.
The only diff is that jaguar is compiling with -DCLOBBER_CACHE_ALWAYS
Is that related?
Thought you should know.
Regards
--
Olivier PRENANT
Neil Conway <[EMAIL PROTECTED]> writes:
> Applied to HEAD.
At this point it would probably be a good idea if a couple of buildfarm
machines were to start testing builds with --disable-integer-datetimes
... any volunteers out there?
regards, tom lane
--
Sent via pgsql-hac
On 31/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> There isn't any functional difference there. I am not sure, but I think
> the reason print.c has its own malloc wrappers instead of depending on
> common.c's is that we use print.c in some bin/scripts/ programs that
> do not want common.c too
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> So, it looks like:
> 1. describe malloc's the cells to zero, but print just does a local
> calloc without any initialisation.
There isn't any functional difference there. I am not sure, but I think
the reason print.c has its own malloc wrappers inste
Brendan Jurd wrote:
1. describe malloc's the cells to zero, but print just does a local
calloc without any initialisation.
Um, calloc is the same as malloc + zero. Those two seem identical to me.
2. describe only does an mbvalidate for WIN32, but print does it in all cases.
There's this c
PFC wrote:
Hello,
So, I embarked (yesterday) on a weekend project to add a new
feature to Postgres...
I use PHP with persistent connections and always have been bothered
that those very small AJAX queries (usually simple selects returning 1
row) take more CPU in postgres to pa
On Fri, Mar 28, 2008 at 2:04 PM, ITAGAKI Takahiro <
[EMAIL PROTECTED]> wrote:
>
> "Gokulakannan Somasundaram" <[EMAIL PROTECTED]> wrote:
>
> > I think the creation of minimal_tuple in the middle is a overhead which
> can
> > be avoided by creating a mem-map and directly creating the minimal_tuple
PFC wrote:
Hello,
So, I embarked (yesterday) on a weekend project to add a new
feature to Postgres...
I use PHP with persistent connections and always have been
bothered that those very small AJAX queries (usually simple selects
returning 1 row) take more CPU in postgres to parse &
Hello,
So, I embarked (yesterday) on a weekend project to add a new feature to
Postgres...
I use PHP with persistent connections and always have been bothered that
those very small AJAX queries (usually simple selects returning 1 row)
take more CPU in postgres to parse & plan than
27 matches
Mail list logo
