Hello
this proposal replace older unsuccessful proposal "user exception" -
http://archives.postgresql.org/pgsql-hackers/2005-06/msg00683.php
It allows only add more parameters to RAISE statement::
syntax:
RAISE [NOTICE|WARNING|EXCEPTION] literal [, params]
[WITH (eparam=expression, ...)];
p
On Mon, Apr 14, 2008 at 8:45 AM, Dickson dos Santos Guedes
<[EMAIL PROTECTED]> wrote:
> On Sat, Apr 12, 2008 at 7:43 PM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> > I was going to try this patch out, but it would not apply. Seems that
> > where the patch should have &, it has & instead. Has t
Why limit ourselves with Oracle? How all major proprietary RDBMSs do it.
Thanks for the links. Very interesting.
The DB2 document especially mentions an important point : in order to make
their planner/optimizer smarter, they had to make it slower, hence it
became crucial to cache the plans
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I would be quite happy with that, but before we go down that path I'd
> like to know why the MSVC builds aren't failing now from this when the
> MinGW builds are.
Maybe the MSVC linker is willing to bind libpq's call to a safestat copy
extracted from
Tom Lane wrote:
In libpq, it's only used in one place to check if a file is present,
and one then in the SSL code to determine permissions and such (which
means it's being ignored on win32).
Maybe we could finess the problem by tweaking libpq to not use stat()
at all on Windows.
On Sat, Apr 12, 2008 at 7:43 PM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> I was going to try this patch out, but it would not apply. Seems that
> where the patch should have &, it has & instead. Has this somehow
> been HTML entity-ified?
Hi Brendan,
You are right, I don't now why this occur
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> If we do this, should we remove RECHECK from the CREATE OPERATOR CLASS
>> syntax altogether, or leave it in but treat it as a no-op (probably
>> with a warning)?
> I think, it should be a error, but not a syntax error - hint should point to
> use
>
Tom, All:
> Well, I can provide an easy example: my first patch [1].
A second one would be Meredith's original QBE patch. While we wouldn't have
ever included it in the core code, it would have been nice if she'd gotten a
reply explaining why.
More importantly, we *think* we haven't missed an
All,
BTW, the lead developer for ReviewBoard stopped by the PostgreSQL booth at
LUGRadio this weekend. He was interested in the possibility of us using
ReviewBoard, but not very interested in adding an e-mail interface to the
software.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
--
Sent
Brendan Jurd escribió:
> I'd like to submit my first version of this patch for review. I have
> introduced a new struct in print.h called printTableContent, which is
> used to compose the contents of a psql table. The methods exposed for
> this struct are as follows:
Looks cool -- on a first re
I've committed changes that move the determination of whether recheck is
required into the index AMs. Right now, GIST and GIN just always set
the recheck flag to TRUE. Obviously that control should be pushed down
to the opclass consistent() functions, but I don't know that code well
enough to be
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Is there not a (3) which has it included in all frontend code *except*
> libpq? Do we have a define to do that off?
Offhand I can't think of one.
> In libpq, it's only used in one place to check if a file is present,
> and one then in the SSL code to
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Cygwin is now building happily, but MinGW is now broken on libpq.
> > It looks like libpq now needs dirmod.o or maybe libpgport.a. What I
> > really don't understand though is why MinGW is broken but MSVC
> > isn't.
>
> I don't think
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom - was there a reason it now runs in FRONTEND as well, or was that
> an oversight?
I did do that intentionally because I was worried about "frontend"
code maybe expecting stat to work fully. Like pg_standby for example.
I think the immediate probl
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I'm confused about the current state of the pgwin32_safestat stuff.
Me too. I tried to fix it a couple of days ago, but seem to have only
moved the problem around :-(
> Cygwin is now building happily, but MinGW is now broken on libpq. It
> looks lik
Andrew Dunstan wrote:
>
> I'm confused about the current state of the pgwin32_safestat stuff.
> Cygwin is now building happily, but MinGW is now broken on libpq. It
> looks like libpq now needs dirmod.o or maybe libpgport.a. What I
> really don't understand though is why MinGW is broken but MSVC
I'm confused about the current state of the pgwin32_safestat stuff.
Cygwin is now building happily, but MinGW is now broken on libpq. It
looks like libpq now needs dirmod.o or maybe libpgport.a. What I really
don't understand though is why MinGW is broken but MSVC isn't.
cheers
andrew
On Sun, Apr 13, 2008 at 2:26 PM, PFC <[EMAIL PROTECTED]> wrote:
> > > Oracle keeps a statement/plan cache in its shared memory segment (SGA)
> > > that greatly improves its performance at running queries that don't
> > > change very often.
> Can we have more details on how Oracle does it
On Sun, Apr 13, 2008 at 02:26:04PM +0200, PFC wrote:
> * global plan cache in shared memory, implemented as hashtable, hash key
> being the (search_path, query_string)
> Doubt : Can a plan be stored in shared memory ? Will it have to be copied
> to local memory before being executed ?
Frankly,
On Sat, 12 Apr 2008, Alexander W?hrer wrote:
I'm working on Windows XP SP2 (stack limit 3500 kb) and deployed
successfully my application (doing some external Web service calling)
inside PostGre 8.3.0.
Unfortunatelly, the application needs at least 3 Threads and will run
for quite some time.
On Fri, Apr 11, 2008 at 12:34 PM, PFC <[EMAIL PROTECTED]> wrote:
Well, I realized the idea of global prepared statements actually
sucked, so I set on another approach thanks to ideas from this list,
this is
caching query plans.
Well, that's a blatantly bad realization. Perhaps you
Would it be possible to store plans with an indication of the
search path that was used to find tables, and for temp tables
some snapshot of the statistics for the table if any?
My suspicions are that:
* where you have a lot of short-lived connections then actually
they will often use the defau
On Tue, Mar 25, 2008 at 2:41 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > This makes me wonder whether print.c could offer something a bit more
> > helpful to callers wishing to DIY a table; we could have a
> > table-building struct with methods like a
Another issue with plan caches, besides contention, in Oracle at least, is
shared memory fragmentation (as plans aren't all the same size in memory ...)
But this cache is very helpful for developments where every query is done via
prepare/execute/deallocate. I've seen it a lot on java apps, the
24 matches
Mail list logo
