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)
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, properly
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 cycle.
[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 me. :-)
FYI, I
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 any
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 of
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 flags to
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
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,
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
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 there
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
[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).
I
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
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
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
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 work
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 :-)
(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
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 not
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 the copy
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
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 PROTECTED]
Josh Berkus josh@agliodbs.com 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
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/pgSQL
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 bottom line
26 matches
Mail list logo
