> > How much effort would it be to add EXPLAIN/EXPLAIN ANALYSE capability to
> > pl/pgsql functions?
> >
> > what I mean, is either a special mode, where "SELECT my_plpgsql_func()"
> > would print all query plans instead or in addition to executing them, or
> > some way for EXPLAIN to pass some fl
> That's exactly the approach I don't want to take. To implement our
> quoting-escape additions, we'll have to stop relying on sprintf and
> implement for ourselves whatever "standard C" escapes we want to
> support.
Ok - then it seems like it might make sense to implement PQexecf() in
terms o
> I don't necessarily object to PQexecf() as a shortcut for some
> multi-step operation, but I don't think you've got the format string
> semantics down yet.
I'm thinking that we could start with the "standard" conversion
specifiers - those are well understood and would be expected by just
about
> [EMAIL PROTECTED] wrote:
> > > I note that the nominal schedule
> > > http://www.postgresql.org/developer/roadmap
> > > says that all major proposals should have been made and reviewed at
> > > least a month ago.
> >
> >
> > Consider me spanked... (and quit giggling Bruce).
>
> Awe, you got
> It's important to get the *right* interface into the first release
> that has it.
Agreed, that's why I proposed the right interface to begin with :-)
> The day before feature freeze is way too late for
> blue-sky design IMHO.
Ok, I can certainly bring this up again in the next release cyc
> Way too late for 8.3 --- if we were going to do something like this,
> we should think first and program later. In particular, blindly
> adopting the sprintf format string definition doesn't seem very helpful.
> The sorts of escapes I'd want to have are "properly quoted SQL
> identifier", "prope
While cleaning up some pg_migrator code
(http://pgfoundry.org/projects/pg-migrator/) it occurred to me that a
typical libpq client application spends a lot of code constructing SQL
commands. The code typically looks like this:
a) allocate enough room to hold the command
b) sp
> > Not that I think that anyone owning both a law degree and a computer
> > in 2007 should legitimately be able to plead innocence here. FAST
> > Australia's lawyers are making themselves look like idiots, and the
> > same for every other company tacking on such notices. I think the
> > real bot
> > If anyone is interested, let me know and I'll add this to my ToDo
> > list.
>
> The Sun benchmarking team needs this. However, we need to be able to feed
> the data into some kind of mass analysis ala pg_fouine so that we can do
> overall performance analysis.
I've also included a PL/pgSQ
> Josh Berkus writes:
> > In recent versions, we've changed the logging of function executions so
> > that only the function call is logged, and not any of the queries which it
> > may execute internally. While most of the time this method is superior
> > for performance analysis, in applicati
On Wed, 2007-01-31 at 11:38 -0800, elein wrote:
> - Forwarded message from elein <[EMAIL PROTECTED]> -
>
> To: pgsql-general@postgresql.org
> Cc: elein <[EMAIL PROTECTED]>
> Subject: [GENERAL] 8.2.1 Compiling Error
> Mail-Followup-To: pgsql-general@postgresql.org
> From: elein <[EMAIL PRO
> >> You're right - we need the copy in the postmaster (to setup shared
> >> memory and LW locks), and we need them in the backends too.
>
> > Just make sure you don't load the libraries in bgwriter et al ...
>
> I see that Korry's patch doesn't do that, but I'm wondering why exactly.
> In a Unix
> > And, shared_preload_libraries is processed (in the postmaster) before
> > the shared-memory segment is created, so a shared_preload_library can
> > call RequestAddinShmemSpace() and RequestAddinLWLocks(), but a
> > local_preload_library cannot.
>
> That doesn't seem like an issue though, since
> Actually ... I take that back. I was thinking of the original purpose
> of preload_libraries, which was strictly performance optimization.
> But in the new world of plugins there may be functional reasons for
> wanting libraries to be loaded into backends --- and
> shared_preload_libraries is no
(working on the PL debugger...)
It appears that the libraries listed in shared_preload_libraries will
*not* be inherited by spawned backends on Win32 platforms.
Do we have to do something special to make that work?
Using ProcessExplorer (from sysinternals.com), I can see that my plugins
are loa
> > Some years ago there was discussion of consistently P-ifying *all* those
> > macros, but it didn't get done; I think Thomas or somebody objected that
> > it would make gram.y needlessly harder to read.
>
> Are there many people who read gram.y on a regular base?
I can't seem to put it down :
> Thought I would do a poll of what is happening in the world for 8.3. I have:
>
> Alvaro Herrera: Autovacuum improvements (maintenance window etc..)
> Gavin Sherry: Bitmap Indexes (on disk), possible basic Window functions
> Jonah Harris: WITH/Recursive Queries?
> Andrei Kovalesvki: Some Win32
> P = Parser. The reason for the _P is just to avoid conflicts with
> other definitions of the macro name, either in our own code or various
> platforms' header files. We haven't been totally consistent about it,
> but roughly speaking we've stuck _P on when it was either known or
> seemed likely
I can't find an authoritative answer to this question.
Many of the keywords listed in keywords.c are defined with symbolic
names that end in '_P' (underscore P).
What differentiates those keywords from the other keywords? What does
the 'P' stand for?
Are those PostgreSQL-specific keywords (i.e.
Well, clearly you should only assign meaningful values to variables, but
I don't see anything wrong with omitting an initializer, initializing
the variable before using it, and letting the compiler warn you if you
forget to do this correctly.
The problem that that introduces is that you
<[EMAIL PROTECTED]> writes:
> initializers also force you to declare variables in the scope where they
> are needed. Instead of declaring every variable at the start of the
> function, it's better to declare them as nested as practical (not as
> nested as possible, but as nested as practical
Yeah, I agree with that. But as Andrew noted, we don't really have any
hard and fast coding rules --- the only guideline is to do your best to
make your code readable, because other people *will* have to read it.
I'm not really looking for hard/fast rules. Just picking brains.
In t
> Shouldn't we turn on warnings by the compiler on uninitialized
> variables? This can also be helpful.
Those warnings should already be enabled, at least with GCC.
Yes, the compiler can detect unitialized variables,
But, that introduces a new problem. There are a lot of tools out the
The disadvantage of using initializers is that you end up contorting the code
to allow you to squeeze things into the initializers and it limits what you
can do later to the code without undoing them.
For example, if later you find out you have to, say, lock a table before the
itupdesc init
I've noticed a trend in the PostgreSQL code base - for some reason, we tend to avoid initializing automatic variables (actually, the code base is pretty mixed on this point).
For example in _bt_check_unique() we have:
static TransactionId
_bt_check_unique(Relation rel, IndexTuple itup, Rel
EnterpriseDB has created a new project at pgFoundry - http://pgfoundry.org/projects/pg-migrator/
pg_migrator is a tool that can in-place upgrade existing data without the usual dump/reload cycle.
The pg_migrator project site (at pgFoundry) contains a complete implementation of the functional
26 matches
Mail list logo
