With a recent snapshot of CVS HEAD:
make[1]: Leaving directory `/home/nconway/build-pgsql-cvs/src/backend/parser'
gcc -O0 -g -Wall -Wmissing-prototypes -Wmissing-declarations
-I/home/nconway/pgsql/src/interfaces/libpq -I../../../src/include
-I/home/nconway/pgsql/src/include -D_GNU_SOURCE
GCC supports the -Wshadow command-line option:
-Wshadow
Warn whenever a local variable shadows another local
variable, parameter or global variable or whenever a
built-in function is shadowed.
Currently, enabling this for the PostgreSQL tree produces a lot
Tom Lane [EMAIL PROTECTED] writes:
Neil Conway [EMAIL PROTECTED] writes:
Currently, enabling this for the PostgreSQL tree produces a lot of
warnings.
How many is a lot?
Maybe a couple hundred or so, but most of the warnings are derived
from a few globals with common names -- I would guess
Tom Lane [EMAIL PROTECTED] writes:
I wouldn't object to something that catches shadowings of parameters
or local variables, but I think the flag as defined is not very
useful.
On closer examination, that seems like a prescient comment. There are
about 1100 distinct warnings enabled by this
Robert Treat [EMAIL PROTECTED] writes:
Seems merging the two would work... attlogpos, the attributes
logical position.
Unless anyone has any further objections, I'll switch to using attlogpos.
-Neil
---(end of broadcast)---
TIP 2: you can get
Tom Lane [EMAIL PROTECTED] writes:
This is a backwards-compatibility hangover.
But I'd not want to break it just because someone thinks the hack is
ugly. It was ugly from day one.
I agree it shouldn't be removed -- I was just curious to see what was
using it. It's certainly ugly, though.
Tom Lane [EMAIL PROTECTED] writes:
attpos is a horrid choice of name, because no one will be able to
remember which of attnum and attpos is which. Pick a more
distinct name. Offhand the best thing I can think of is attlognum
or attlogpos.
Actually, I deliberately chose attpos rather than
I noticed the following code in src/backend/rewrite/rewriteDefine.c,
circa line 390:
/*
* Are we converting a relation to a view?
*
* If so, check that the relation is empty because the storage
* for the relation
I'd like to add a new column to pg_attribute that specifies the
attribute's logical position within its relation. The idea here is
to separate the logical order of the columns in a relation from the
on-disk storage of the relation's tuples. This allows us to easily
quickly change column order,
I'd like to add a new column to pg_attribute that specifies the
attribute's logical position within its relation. The idea here is
to separate the logical order of the columns in a relation from the
on-disk storage of the relation's tuples. This allows us to easily
quickly change column order,
Peter Eisentraut [EMAIL PROTECTED] writes:
I don't think you can speak of bloat for pg_attribute. But you
can speak of a problem when you want to do the old col = col + 1 in
the presence of a unique index.
I'm sorry, but I'm not sure what either of these comments mean -- can
you elaborate?
Jon Jensen [EMAIL PROTECTED] writes:
You're just saying it'd break old dumps, right? I'd assume COPY FROM
would use attpos ordering when writing out columns, or that every
user-visible interaction with the table pretends the columns are in
attpos order. So dumps would break no more or less
Josh Berkus [EMAIL PROTECTED] writes:
It seems certain that the next release, in 6-9 months, will have at
a minimum the Windows port and ARC, if not Slony-I as well.
Given all that, don't people think it's time to jump to 8.0?
It seems a little premature to speculate on what features may or
Peter Eisentraut [EMAIL PROTECTED] writes:
The time from release 7.3 to release 7.4 was 355 days, an all-time
high. We really need to shorten that.
Why is that?
-Neil
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please
Peter Eisentraut [EMAIL PROTECTED] writes:
First, if you develop something today, the first time users would
realistically get a hand at it would be January 2005. Do you want
that? Don't you want people to use your code?
Sure :-) But I don't mind a long release cycle if it is better for
Matthew T. O'Connor [EMAIL PROTECTED] writes:
So 7.4 took about 4.5 months to get from feature freeze to release.
I think feature freeze is the important date that developers of new
features need to concern themselves with.
Rather than the length of the release cycle, I think it's the length
Marc G. Fournier [EMAIL PROTECTED] writes:
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
0. As you say, make it known to the public. Have people test their
in-development applications using a beta.
and how do you propose we do that? I think this is the hard part
(1) Make the beta more
Hannu Krosing [EMAIL PROTECTED] writes:
For me, the start of transaction is not about time, but about grouping
a set of statements into one. So making the exact moment of start be
the first statement that actually does something with data seems
perfectly reasonable.
This might be a perfectly
Tom Lane [EMAIL PROTECTED] writes:
That's defensible when the user issued the BEGIN himself. When the
BEGIN is coming from some interface library's autocommit logic, it's
a lot less defensible. If you consult the archives, you will find
actual user complaints about why is now() returning a
Bruce Momjian [EMAIL PROTECTED] writes:
Is there a TODO here?
You needn't add one: I hope to tackle this during the 7.5 dev cycle.
-Neil
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
bpalmer [EMAIL PROTECTED] writes:
I'm trying to figure out what version of a source code I have. I know
it's a 7.2 release, but how can I find out of it's 7.2, 7.2.3, 7.2.4,
etc. FROM THE SOURCE CODE, not from compiling (it doesn't compile, it's
testing code).
Look in configure.in:
Bruce Momjian [EMAIL PROTECTED] writes:
Now, the disadvantages of large kernel cache, small PostgreSQL buffer
cache is that data has to be transfered to/from the kernel buffers, and
second, we can't control the kernel's cache replacement strategy, and
will probably not be able to in the near
Larry Rosenman [EMAIL PROTECTED] writes:
You might also look at Veritas' advisory stuff.
Thanks for the suggestion -- it looks like we can make use of
this. For the curious, the cache advisory API is documented here:
http://www.lerctr.org:8458/en/man/html.7/vxfsio.7.html
[EMAIL PROTECTED] writes:
I am trying to catch the UPDATE 0 condition in postgresql.
I have tried it using triggers, but they are only fired when there
effectively is an update.
You could try using an AFTER STATEMENT trigger (which will be invoked
even if zero rows are updated), and checking
Bruce Momjian [EMAIL PROTECTED] writes:
Another idea --- if fsync() is slow because it can't find the dirty
buffers, use write() to write the buffers, copy the buffer to local
memory, mark it as clean, then open the file with O_SYNC and write
it again.
Yuck.
Do we have any idea how many
Jan Wieck [EMAIL PROTECTED] writes:
We can't resize shared memory because we allocate the whole thing in
one big hump - which causes the shmmax problem BTW. If we allocate
that in chunks of multiple blocks, we only have to give it a total
maximum size to get the hash tables and other stuff
Jan Wieck [EMAIL PROTECTED] writes:
This patch contains the still not yet ready performance improvements
discussed over the couple last days.
Cool stuff!
The buffer replacement strategy is a slightly modified version of
ARC.
BTW Jan, I got your message about taking a look at the ARC code;
Josh Berkus [EMAIL PROTECTED] writes:
Oh, and how about we kill the Image Map of major developers? It's about 4
years out of date, and makes developers.postgresql.org load like molasses in
January.
Personally, I don't really see the need for developer.postgresql.org
to be a separate
On Mon, 2003-11-03 at 04:21, Hannu Krosing wrote:
Neil Conway kirjutas E, 03.11.2003 kell 08:07:
(2) ISTM that we can set POSIX_FADV_RANDOM for *all* indexes, since the
vast majority of the accesses to them shouldn't be sequential.
Perhaps we could do it for all _leaf_ nodes, the root
On Mon, 2003-11-03 at 10:01, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
POSIX_FADV_RANDOM doesn't effect the page cache, it just determines how
aggressive the kernel is when doing readahead (at least on Linux, but
I'd expect to see other kernels implement similar behavior).
I
On Mon, 2003-11-03 at 11:11, Tom Lane wrote:
Why not? The advice says that you're going to access the data
sequentially in the forward direction. If you're not going to back up,
there is no point in keeping pages in cache after they've been read.
The advice says: I'm going to read this data
On Mon, 2003-11-03 at 12:17, Hannu Krosing wrote:
Can you use combinations like ( FADV_NOREUS | FADV_SEQUENTIAL )
You can do an fadvise() for FADV_SEQUENTIAL, and then another fadvise()
for FADV_NOREUSE.
-Neil
---(end of broadcast)---
TIP 4:
On Mon, 2003-11-03 at 09:38, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
Given a Relation and an advice, this would:
(a) propagate the advice for this relation to all the open FDs for the
relation
All? You cannot affect the FDs being used by other backends.
Sorry, I meant
On Mon, 2003-11-03 at 14:24, Manfred Spraul wrote:
Neil: what about calling posix_fadvise for the whole file immediately
after issue_xlog_fsync() in XLogWrite? According to the comment, it's
guaranteed that this will happen only once.
Or: add an posix_fadvise into issue_xlog_fsync(), for
In the BufferDesc struct, there seem to be two ways to mark a buffer
page as dirty: setting the BM_DIRTY bit mask in the 'flags' field of the
struct, and setting the 'cntxDirty' field to true. What is the
difference between these two indications of a page's dirtiness?
Or, more to the point, is
A couple days ago, Manfred Spraul mentioned the posix_fadvise() API on
-hackers:
http://www.opengroup.org/onlinepubs/007904975/functions/posix_fadvise.html
I'm working on making use of posix_fadvise() where appropriate. I can
think of the following places where this would be useful:
(1) As
On Mon, 2003-11-03 at 01:07, Neil Conway wrote:
(1) As Manfred originally noted, when we advance to a new XLOG segment,
we can use POSIX_FADV_DONTNEED to let the kernel know we won't be
accessing the old WAL segment anymore. I've attached a quick kludge of a
patch that implements this. I
While reading through src/backend/storage/buffer/README, I noticed that
the following text seems to no longer be correct:
As of 7.1, the only operation that removes tuples or compacts
free space is (oldstyle) VACUUM. It does not have to implement
rule #5 directly, because
On Thu, 2003-10-30 at 23:13, Bruce Momjian wrote:
If we do a short cycle, will we have enough features to justify a
release? We could try to get PITR and Win32 done by January 1 and see
if that can happen.
It's worth noting that we've thought about doing quick major releases
in the past,
On Mon, 2003-10-27 at 15:31, Jan Wieck wrote:
Well, partial solution isn't quite what I would call it, and it surely
needs integration with sequential scans. I really do expect the whole
hack to fall apart if some concurrent seqscans are going on
I'd rather see us implement a buffer
On Tue, 2003-10-28 at 10:01, Bruce Momjian wrote:
OK, that attached patch completes this item. I did not document
--describe-config at the top as an accepted arg, but there was already a
--name=value line.
Why does '--name=value' suffice as documentation for
'--describe-config'? I think you
On Tue, 2003-10-28 at 12:57, Bruce Momjian wrote:
OK, but it is going to look kind of big up there and isn't of general
usefulness. Still want it?
Well, as a matter of principle, I think it belongs there: if it's a
command-line option, it should be documented in the section that claims
to
On Sun, 2003-10-26 at 19:22, Gaetano Mendola wrote:
Hi all,
why START TRANSACTION READ ONLY is allowed
and not BEGIN READ ONLY ?
As Chris KL points out, it's not required by the standard (since BEGIN
isn't part of the standard to begin with). I suppose we could add it,
but it seems a little
On Sat, 2003-10-25 at 21:29, Bruce Momjian wrote:
configure --enable-debug will use -g for the compile, and with
optimization.
I'm just curious: would there be any benefit to using -g3 when
--enable-debug is specified and -g3 is supported by gcc? From the gcc
man page:
-glevel
[...]
On Sun, 2003-10-26 at 17:24, Oliver Elphick wrote:
If it were possible to have two separate versions of the PostgreSQL
packages installed simultaneously, it would be simple to do database
upgrades by dumping from the old version and uploading to the new.
You'd need some mechanism to prevent
On Wed, 2003-10-22 at 01:08, Bruce Momjian wrote:
Do you think I include every user-visible change in the release notes?
It would be 2-3x longer, and probably not more useful.
Part of the reason the release notes are read is
because they are _readable_
On the contrary, I think we could do a
On Wed, 2003-10-22 at 11:43, Andreas Joseph Krogh wrote:
So, is an initdb from beta4 required or not?
Yes, it is. This should probably be mentioned in the announcement when
it is sent out.
-Neil
---(end of broadcast)---
TIP 5: Have you checked
On Wed, 2003-10-22 at 13:26, Tom Lane wrote:
We do already have a practice of adding notes about significant changes
to release.sgml as they are made. That's relatively new though, and I
dunno if it's helped Bruce prepare the finished release notes or not.
Right, we also did a pretty bad job
On Wed, 2003-10-22 at 00:41, Christopher Kings-Lynne wrote:
It would be pretty strange to use those as a default --- I am not
inclined to mention it in the release notes --- we don't mention every
change, only significant ones.
Personally, I think that's a fairly silly policy!
I agree --
On Fri, 2003-10-17 at 16:22, Greg Stark wrote:
If it's just a matter of all the read i/o from vacuum then we're best off
sleeping for a few milliseconds every few kilobytes. If it's the cache then
we're probably better off reading a few megabytes and then sleeping for
several seconds to allow
On Wed, 2003-10-15 at 11:43, [EMAIL PROTECTED] wrote:
Hello,
I'm a student who use postgresql. I'd like to debug postgres source code.I
tried to use ddd in linux. The thing what I want to do is debugging
backend part.How can I do that. The commands that I used until now are
following.
1.
On Wed, 2003-10-15 at 13:54, Marc G. Fournier wrote:
ams=# create index company_1.traffic_ip on company_1.traffic using btree (
ip_id ) ;
ERROR: parser: parse error at or near . at character 27
RTM:
name
The name of the index to be created. No schema name can be
On Tue, 2003-10-14 at 15:57, Alvaro Herrera Munoz wrote:
On Tue, Oct 14, 2003 at 07:52:55PM +, Jon Jensen wrote:
Other projects I've worked on have such a list, and each commit message is
followed by a complete diff (usually with -u for readability) so even
non-committers can do a code
On Sun, 2003-10-12 at 05:42, ivan wrote:
Hi, How can i check how many tules has my declared cursor ?
You can't know the # of tuples produced by a query without producing its
entire result set. Since DECLARE doesn't actually evaluate the query you
specify (... which is the whole point of using
On Mon, 2003-10-06 at 16:21, Joshua D. Drake wrote:
postgres=# create user with encrypted password '98wq7912a';
CREATE USER
postgres=# create user with encrypted password '98wq7912a';
ERROR: CREATE USER: user name with already exists
So, what are we doing about this? If we're considering it
On Wed, 2003-10-08 at 21:44, Bruce Momjian wrote:
Agreed. Do we set them all to -O2, then remove it from the ones we
don't get successful reports on?
I took the time to compile CVS tip with a few different machines from
HP's TestDrive program, to see if there were any regressions using the
new
Is the following behavior intentional? If so, what's the reasoning
behind it?
nconway=# select 1::bit;
bit
-
0
(1 row)
nconway=# select '1'::bit;
bit
-
1
(1 row)
nconway=# select X'1'::bit;
bit
-
0
(1 row)
nconway=# select 1::bit varying;
ERROR: cannot cast type integer to
On Wed, 2003-10-08 at 14:31, Bruce Momjian wrote:
Well, this is really embarassing. I can't imagine why we would not set
at least -O on all platforms.
ISTM the most legitimate reason for not enabling compilater
optimizations on a given compiler/OS/architecture combination is might
cause
On Sun, 2003-10-05 at 17:21, Bruce Momjian wrote:
Sure, check out the developers web page. It has some basic outlines,
and an FAQ. After that, it is mostly digging. You will need an editor
that supports tags or some way to pull symbols out of the code, and
hopefully cross-references.
On Sun, 2003-10-05 at 17:45, Bruce Momjian wrote:
Neil Conway wrote:
Depending on what part of the source you're interested in, a book on
DBMS implementation might also be useful, such as
Wow, $100.
Well, it's a CS textbook -- I have several textbooks this semester that
are $100.
Does
On Sun, 2003-10-05 at 19:58, Tom Lane wrote:
That's a fairly useless place to put it, though, since someone would
only think to look at sort_mem if they already had a clue. It should
be mentioned under bulk data load (in performance tips chapter)
Attached is a doc patch that does this. The
Is this a bug?
(using CVS code from yesterday)
nconway=# create view baz (a,b) as select 'hello', 'world';
WARNING: column a has type unknown
DETAIL: Proceeding with relation creation anyway.
WARNING: column b has type unknown
DETAIL: Proceeding with relation creation anyway.
CREATE VIEW
On Thu, 2003-10-02 at 10:16, Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
nconway=# create view baz (a,b) as select 'hello', 'world';
WARNING: column a has type unknown
DETAIL: Proceeding with relation creation anyway.
It's always done that, although the spelling of the notice
On Wed, 2003-10-01 at 09:14, Robert Treat wrote:
Maybe I've mis-read Joshua's intentions, but I got the impression that
this 7.3 maintainer would follow the patches list and backport patches
whenever possible. This way folks coding for 7.4/7.5 can stay focused on
that, but folks who can't
On Wed, 2003-10-01 at 11:48, Joshua D. Drake wrote:
Sure but businesses don't like to upgrade unless they have too.
Granted, but maintaining old releases doesn't come at zero cost. It may
benefit some users, but the relevant question is whether that benefit is
worth the cost. The time someone
On Wed, 2003-10-01 at 20:25, Jingren Zhou wrote:
From the document, it seems that PREPARE/EXECUTE works only in the same
session. I am wondering whether postgres can prepare a query (save the plan)
for difference backends.
The decision to store prepared statements per-backend, rather than in
On Wed, 2003-10-01 at 22:43, Tom Lane wrote:
Another issue is that we currently don't have a mechanism for flushing
query plans when they become obsolete (eg, an index is added or
removed). Locally-cached plans are relatively easy to refresh: just
start a fresh session. A shared plan cache
have been
+removed.
_
***
*** 177,190
Object Manipulation
Make CREATE SEQUENCE grammar more SQL1999 standards compliant (Neil)
! Add FOR EACH STATEMENT statement-level triggers (Neil Conway
I think most people on this list will agree that having OIDs on user
tables is a Bad Thing. For some previous discussion of why, see:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg27374.html
My understanding of the conclusion of previous discussions on this topic
is that getting rid of OIDs
On Mon, 2003-09-29 at 18:37, Tom Lane wrote:
It doesn't seem to me that this really buys much. What we really want
is a way for a dump/reload to remove OIDs from tables that formerly had
them; otherwise people will not easily be able to migrate their existing
tables away from having OIDs.
On Mon, 2003-09-29 at 18:18, [EMAIL PROTECTED] wrote:
The GUC route sounds good. I'd like to see ctid handling beefed up at the
same time. For example, some operators such as != would be nice and might
ease the pain a little for people used to using oids as their tuple id :)
Are we
Is there a reason why there haven't been any 7.4 beta announcements on
the main website?
-Neil
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
On Tue, 2003-09-23 at 22:45, Li YueXin wrote:
I found postgresql running on the multi CPU machine doesn't have
better performance than single CPU machine. Can you explain the
reason?
In addition to what Christopher Browne suggests, keep in mind that
PostgreSQL spawns a separate Unix process
On Sat, 2003-09-20 at 06:14, Jeff wrote:
Well, that depends. First, turn on stats collecting and run VACUUM
ANALYZE. That will collect some data about your data which helps the
planner make a good choice.
The statistics collector and the statistics collected by ANALYZE have
nothing to do with
I'm working on adding support for unique indexes to the hash index code.
The majority of the code is finished, with the exception of the changes
to locking. My proposed changes are below -- if anyone sees a better way
to do things, let me know.
There's lots of info on the locking scheme used by
On Mon, 2003-09-15 at 07:32, Andrew Dunstan wrote:
This will probably take a while to make its way into vendor kernels, and
even then we'll need to keep the warnings in the docs for people running
older kernels. I am not sure at this stage what its status is for the 2.6
kernel series.
The 2.6
On Thu, 2003-09-04 at 13:14, Kurt Roeckx wrote:
tablecmds.c: In function `validateForeignKeyConstraint':
tablecmds.c:3546: warning: dereferencing type-punned pointer will break
strict-aliasing rules
So, what should we do with this?
The recommended way to deal with is to put them into a
On Mon, 2003-09-08 at 11:09, Gaetano Mendola wrote:
Tom Lane [EMAIL PROTECTED] wrote:
I see no value at all in an assert. The code will dump core just fine
with or without an assert ...
Right but an assert can display information about the file and line number
without debug the
This is an FAQ, BTW -- try searching the archives again. It's also
mentioned in the documentation:
http://candle.pha.pa.us/main/writings/pgsql/sgml/functions-aggregate.html
On Thu, 2003-09-04 at 11:10, Dennis Bjorklund wrote:
On Thu, 4 Sep 2003, Shridhar Daithankar wrote:
It can not be
Should this produce a warning?
nconway=# create table a (b int4 unique);
NOTICE: CREATE TABLE / UNIQUE will create implicit index a_b_key for
table a
CREATE TABLE
nconway=# create table c (d int8 references a (b));
NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY
check(s)
On Thu, 2003-09-04 at 22:02, Bruce Momjian wrote:
My idea is that if a transaction doing a COUNT(*) would first look to
see if there already was a visible cached value, and if not, it would do
the COUNT(*) and insert into the cache table. Any INSERT/DELETE would
remove the value from the
This TODO item has been completed as of CVS tip, right?
Allow psql to do table completion for SELECT * FROM schema_part
and table completion for SELECT * FROM schema_name.
-Neil
---(end of broadcast)---
TIP 7: don't
I'm seeing the following with the current CVS code on my Linux dev box:
$ make maintainer-clean
$ ./configure --enable-depend --enable-cassert --enable-debug
--prefix=/pgsql --with-openssl
[ ... ]
$ make -s
In file included from bootparse.y:340:
lex.Int_yy.c:1832: warning: no previous prototype
On Thu, Aug 28, 2003 at 05:22:36PM +0530, Shridhar Daithankar wrote:
BTW, what is the sway of switching disk IO scheduler in 2.6? Could not find
any references to sysctl switching. Andrew Morton's TODO list still list it
as TODO.
Sorry, I was mistaken: you can switch I/O schedulers by
On Thu, Aug 28, 2003 at 01:00:44PM -0700, Sean Chittenden wrote:
Other than you feeling uneasy about the possibility of uncovering bugs
because this hasn't been widely done like this before, do you have any
other concerns, or do you think the possibility of finding bugs very
likely?
In case
On Fri, Aug 29, 2003 at 12:06:59AM -0300, Marc G. Fournier wrote:
tuning documents is *not* a valid reason for not doing this ... that's
like saying we can make it faster on some operating systems, but because
we're going to have to modify the tuning documents, we're not going to do
it ...
On Sun, Aug 17, 2003 at 12:39:53AM -0400, Bruce Momjian wrote:
I assume this has been addressed?
Yes, Tom checked a fix into CVS for the functions in question.
-Neil
---(end of broadcast)---
TIP 6: Have you searched our list archives?
On Fri, Aug 08, 2003 at 03:32:05PM +0530, Rahul_Iyer wrote:
im currently working on a project that requires batch operations - eg. Batch
insert/update etc. The database im using is PostgreSQL. However, i cannot
find any documentation for batch opeartions on PostgreSQL. Does anyone know
how to
On Thu, Aug 07, 2003 at 03:43:45PM -0700, [EMAIL PROTECTED] wrote:
I used lcov to generate some fancy webpages that shows code coverage of
PostgreSQL 7.3.4 from running our DBT-2 workload (TPC-C derivative)
against it.
Cool -- one thing I've been meaning to do for a while is to get some code
I'm working on writing a script that automatically tests all the
built-in functions. As a first step, I just passed NULL for all
of the arguments for each built-in function. I've attached a
list of the 90 functions that crash the backend when this is done.
Since the culprit functions all seem
On Tue, Aug 12, 2003 at 07:00:35PM +0200, [EMAIL PROTECTED] wrote:
how far have you got with statement-level triggers development?
In PostgreSQL 7.3, statement-level triggers are not supported. In 7.4,
you can define statement-level triggers in C, PL/PgSQL, PL/Python, and
PL/Tcl. One piece of
On Fri, Aug 08, 2003 at 04:00:22PM -0400, Tom Lane wrote:
Prepared statements would be just as much of a problem. I think the
correct answer is simply don't use those features in a pooled
environment.
Well, unless you're prepared to manually manage these resources
yourself (i.e. DEALLOCATE a
On Mon, Aug 11, 2003 at 09:40:25AM +0800, Christopher Kings-Lynne wrote:
Has anyone reviewed the compatibility list for 7.4 yet?
I seem to remember something about us having the unique predicate now or
something?
I hacked up a really simplistic implementation of it, but it wasn't
included in
When I run the regression tests against current sources, I get
failures because bison-generated error messages use parse
error, not syntax error. I vaguely recall running into
this issue before I left for the summer -- did we resolve
it?
[EMAIL PROTECTED] neil]$ uname -a
FreeBSD arch.wavefire.com
On Mon, Aug 04, 2003 at 10:47:36AM +0200, Andreas Pflug wrote:
AFAICS the current implementation still doesn't have a way to access the
affected rowset, so it'a pretty much like a SELECT without a WHERE.
Yeah, unfortunately I didn't get a chance to implement this functionality
during the 7.4
Joe Conway said:
Hmm, same problem. Looks like PL/pgSQL does the right thing, but
plpython will crash also. I don't think plperl supports triggers.
Right -- I only had time to implement support for statement-level
triggers in the backend itself and in PL/PgSQL. Thanks for taking the
time to
On Fri, 2003-04-11 at 17:32, Kevin Brown wrote:
The big overhead in the process model on most platforms is in creation
and destruction of processes. PostgreSQL has a relatively high
connection startup cost. But there are ways of dealing with this
problem other than threading, namely the use
On Wed, 2003-04-02 at 18:00, Marc G. Fournier wrote:
On Wed, 2 Apr 2003, scott.marlowe wrote:
True. But not linking to LGPLd libs would be a bit extreme there.
Correct, we've always had libreadline support, as a compile option
Why is that relevant? libreadline is GPL'd, not LGPL'd.
Folks,
While browsing through the SQL spec (200x draft), I noticed the
following:
set clause list (the list of SET expressions in an UPDATE statement;
section 14.12) allows a contextually typed value specification on the
right-hand side of SET assignments. One of the possibilities for a
On Fri, 2003-03-21 at 12:12, Tom Lane wrote:
I agree that the second of these is bogus. I'm ambivalent about
changing the first; it's odd but perhaps there are apps out there
that depend on it. Any other opinions out there?
For what it's worth, I noticed that the first (DECLARE CURSOR
701 - 800 of 1081 matches
Mail list logo
