I wouldn't call this behavior buggy, but I found it somewhat surprising.
expression_tree_walker() assumes that the walker has already been
invoked on the current node (the node that a given recursive call of
expression_tree_walker() has been invoked on). Therefore, calling
Martin Pitt said:
If you just output a rollback command on exit, then it is already too
late to rescue the pending transaction, so I'm not sure whether that
would help this use case so much.
Well, the DBA can always replay the transaction manually -- I think
notifying the DBA that their
On Sun, 2007-09-16 at 20:34 +0200, Martin Pitt wrote:
users= begin;
BEGIN
[...]
users= \q
$ ...
It would be really nice if psql prompted me whether I wanted to do
this. As it stands, it just rolls back the transaction.
At a minimum, I think we could make the fact that the transaction
has
On Tue, 2007-17-07 at 00:51 +, Chris Bowlby wrote:
Using a temporary table of the same name in repeated calls to a stored
procedure are causing OID failure issues
This is a (well) known bug. The problem arises because plpgsql caches
the query plan used to access the temporary table, which
On Mon, 2007-09-07 at 10:39 -0400, Tom Lane wrote:
When applied to numeric input, stddev_pop produces the same result as
stddev_samp, and var_pop produces the same result as var_samp. This
is because whoever wrote numeric_stddev_internal() forgot that the
divisor is different for the sample
On Thu, 2007-07-05 at 16:32 -0400, Tom Lane wrote:
By and large we don't try to support nonstandard compilers on Linux.
We support icc on Linux, at least to some degree (buildfarm members
mongoose and dugong, for example). I don't see anything wrong with
supporting Sun Studio on Linux, if
On Sat, 2007-02-06 at 14:25 +0200, Frank van Vugt wrote:
BEGIN;
SELECT * INTO STRICT myrec FROM emp WHERE empname = myname;
EXCEPTION
WHEN NO_DATA_FOUND THEN
RAISE EXCEPTION 'employee % not found', myname;
WHEN TOO_MANY_ROWS THEN
RAISE
On Wed, 2007-16-05 at 11:46 -0400, Bruce Momjian wrote:
This has been saved for the 8.4 release
No, this is a bug, and should be fixed in 8.3 and likely backported. I
haven't had a chance to get to it yet, though.
-Neil
---(end of broadcast)---
When integer datetimes are in use, the legal range of the date type
actually exceeds that of the timestamp type. However, the cast from
date = timestamp fails to take this into account:
postgres=# select '01-01-5874896'::date::timestamp;
timestamp
There's a minor bug in the ON_ERROR_ROLLBACK code in psql. In HEAD, at
line 878 the storage pointed to by results is released by a PQclear(),
but is referenced by the PQcmdStatus() calls on lines 898, 899, and 900.
I'm busy at the moment -- if someone wants to fix this (backport to 8.1
please!),
On Mon, 2006-03-20 at 14:27 +0530, Dhanaraj M - Sun Microsystems wrote:
I have fixed a bug which was reported in our mailing group ealier. Can
anybody tell me how i could test my code and then put back?
I'm not sure what you mean; if you're asking how do I submit patches
that fix bugs?, send
On Sat, 2006-03-18 at 15:35 -0600, Ashley Clark wrote:
The call to DNSServiceRegistrationCreate in postmaster.c does
incorrect byte-swapping on the port number which causes the Bonjour
registration call to fail on Intel Macs.
Thanks for the patch -- applied to HEAD and back branches, back to
On Sat, 2006-01-28 at 20:17 +0100, Peter Eisentraut wrote:
This bug was reported to Debian. Comments?
AFAICS I fixed this a few weeks ago (post-8.1.2):
http://archives.postgresql.org/pgsql-committers/2006-01/msg00209.php
http://archives.postgresql.org/pgsql-patches/2006-01/msg00139.php
I get
On Mon, 2006-01-30 at 20:45 -0500, Tom Lane wrote:
You only fixed the bind-parameter case, though, no? The problem is
still rampant in the PLs.
Right: the bug report was specific to the bind parameter case. Domain
constraints should also be checked before returning values of a domain
type from
On Sun, 2006-01-29 at 17:03 -0800, David Fetter wrote:
Another followup, this time with the comment done right.
+ /* Disallow the forbidden_delimiter strings */
+ if (strcspn(cstate-delim, BADCHARS) != 1)
+ elog(ERROR, COPY delimiter cannot be %#02x,
+
On Thu, 2005-12-15 at 11:09 -0800, Jim Klo wrote:
I’m having a similar problem:
ERROR: relation with OID 7121526 does not exist
CONTEXT: SQL statement SELECT * INTO temp tmp_resourcequeue from
resourcequeue where timeblockid in (select timeblockid from tmp_timeblock)
PL/pgSQL function
On Thu, 2005-11-17 at 13:07 -0800, David Fetter wrote:
This is still a bug, or at least a big gotcha.
It's not a bug, merely an unimplemented feature. If no one beats me to
it I'll take a look at doing this for 8.2.
-Neil
---(end of
Denis Vlasenko wrote:
Symptom: even the simplest query
$result = pg_query($db, SELECT * FROM big_table);
eats enormous amounts of memory on server
(proportional to table size).
Right, which is exactly what you would expect. The entire result set is
sent to the client and stored in local
Denis Vlasenko wrote:
The same php script but done against Oracle does not have this
behaviour.
Perhaps; presumably Oracle is essentially creating a cursor for you
behind the scenes. libpq does not attempt to do this automatically; if
you need a cursor, you can create one by hand.
-Neil
Tom Lane wrote:
System catalog lookups generally follow SnapshotNow rules, not MVCC.
So the new function definition is visible as soon as it's committed,
whether you are in a serializable transaction or not.
IMHO this is a bug, or at least not optimal behavior. But per the
discussion on
On Mon, 2005-05-30 at 19:36 +0300, Haluk GÜNÇER wrote:
#0 0x23cf64 in CreatePortal+0x1f4 ()
(gdb) bt
#0 0x23cf64 in CreatePortal+0x1f4 ()
#1 0x23ce28 in CreatePortal+0xb8 ()
#2 0x19c094 in exec_simple_query+0x194 ()
#3 0x19daa8 in PostgresMain+0x1520 ()
#4 0x12f918 in main+0x1e0 ()
Haluk GÜNÇER wrote:
I did it with -n option. The generated core file is attached. I hope it
will help.
The core file itself is not much use -- you need to get a stack trace
from the core file (which I can't do, since I don't have the binaries
you built -- or an HPUX system for that matter).
Neil Conway wrote:
Ah, yeah, that works. Attached is a revised patch -- I'll apply it
tomorrow barring any objections. I also fixed the semi-colon -- thanks
for the review.
Patch applied to HEAD, REL8_0_STABLE, and REL7_4_STABLE. Thanks for the
report, Mark.
-Neil
Tom Lane wrote:
I'm not set on it --- fix it as you suggested.
Attached is a patch that implements this. I'm not especially happy about
the implementation: defining _two_ local macros (that both
doubly-evaluate one of their arguments) is pretty ugly, but I didn't see
a cleaner alternative
Haluk GUNCER wrote:
fixing permissions on existing directory /usr/local/pgsql/data ... ok
creating directory /usr/local/pgsql/data/global ... ok
creating directory /usr/local/pgsql/data/pg_xlog ... ok
creating directory /usr/local/pgsql/data/pg_xlog/archive_status ... ok
creating directory
Tom Lane wrote:
Considering that you're incrementing bufptr inside the macro, it hardly
seems that double-evaluation is a problem: the argument pretty much has
to be a variable. OTOH there is no reason for the input argument to be
treated that way. I'd suggest just one macro [...]
Ah, yeah,
Neil Conway wrote:
I think we _can_ do it that way, it's just a question of whether that is
the best approach. I think the solution I outlined before would work
fine: pass the length of the working buffer to ParseDateTime(), and
reject the input only if the parsing process actually requires
Szcs Gbor wrote:
# create table foo (bar int, constraint foobar check (true));
CREATE TABLE
# \d foo
Table public.foo
Column | Type | Modifiers
+-+---
bar| integer |
Check constraints:
foobar CHECK ()
Yeah, I can repro this with current REL7_4_STABLE
Tom Lane wrote:
I'm too tired to think about this more tonight, but it seems like
the basic point is that we can't just construct a list of pointers
into (a copy of) the original input string.
I think we _can_ do it that way, it's just a question of whether that is
the best approach. I think the
Herman Bos wrote:
vib= select * from bedrag;
ERROR: relation bedrag does not exist
Naturally: there is no such table, regardless of case.
vib= select BEDRAG from sancties;
BEDRAG
(0 rows)
Not with the SQL you provided:
neilc=# select BEDRAG from sancties;
ERROR: relation sancties does
Tom Lane wrote:
There are a lot of fixed-size local buffers in that code. The ones
used in output routines seem defensible since the string to be generated
is predictable. The ones that are used for processing input are likely
wrong. OTOH I'm not eager to throw a palloc into each of those code
Alexander Volk wrote:
configure: WARNING: you should use --build, --host, --target
checking build system type... i386-portbld-freebsd5.4
checking host system type... i386-portbld-freebsd5.4
checking which template to use... freebsd
checking whether to build with 64-bit integer date/time support...
Tom Lane wrote:
Well, if you allow for whitespace between tokens then it's immediately
clear that there is no fixed upper bound.
Good point -- there is no upper bound on the input string, but since we
skip whitespace, AFAICS this shouldn't affect the requirements for the
size of the working
Tom Lane wrote:
I believe that the reason for the local buffer is to hold a downcased
version of the input, which we can compare to the all-lower-case tables
of relevant keywords.
Well, that's one of the reasons, but not the only one. For example, how
do you parse '17 minutes31 seconds'::interval
Tom Lane wrote:
Sorry, s/downcased/downcased and null-terminated/. I have not read the
parsing code in question lately, but offhand it seems like transferring
one token at a time into a work buffer isn't a completely broken idea...
I wouldn't call it broken, but I don't see how it could be done
Mark Dilger wrote:
It appears that any string representation of an interval of length greater
than 76 is rejected. (76 = 51 + 25 = MAXDATELEN + MAXDATEFIELDS). This
appears to be a limitation enforced within function interval_in() in the
file src/backend/utils/adt/timestamp.c
Yeah, this seems
tirny wrote:
any code instructions
***
IF FOUND AND TG_OP = 'UPDATE' THEN
***
END IF;
***
if not found plsql does't break this structure after IF FOUND and proceed
TG_OP = \'UPDATE\', what bring control structures to:
IF FOUND THEN
IF TG_OP = 'UPDATE' THEN
***
END IF;
END IF;
Enrico Weigelt wrote:
BTW: real is an alias to float4 ?
Yes.
-Neil
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Alvaro Herrera wrote:
I believe on Windows the file is called pgpass.conf instead?
The SGML docs pretty consistently only mention ~/.pgpass when
referencing this feature, so I didn't bother mentioning the other name
in the pg_autovacuum README. Perhaps someone should fix the SGML docs to
refer
David B. wrote:
8.0.1 doesn't compile to include plpgsql.o so I can't createlang pl/pgsql.
The 8.0.1 compile does create a plpgsql.so; it is installed under
$prefix/lib.
Why don't you guys provide rpms for the major distributions anyway?
http://www.postgresql.org/ftp/binary/v8.0.1/linux/rpms/
Dan Black wrote:
Need to rename function parameters, so that their names and table fields
names are unmatched.
I don't really see a way to make the error any more obvious in the
current pl/pgsql implementation, unfortunately.
-Neil
---(end of
Richard Neill wrote:
I think that the first query ought to succeed, since although priceband is
ambiguous (it could mean either tbl_prices.priceband or
tbl_instruments.priceband), the information in the WHERE clause means that
they are explicitly equal, and so it doesn't matter which one we use.
[EMAIL PROTECTED] wrote:
I have a PLpgSQL function that returns a string (varchar): if this string
is over 256 characters long then the last three characters are corrupted:
replaced by the string ' (.'
I'm skeptical: there is nothing special about 256 characters as far as
the varchar
Richard Sang wrote:
I have a view defined as :
create view calling_view as
(
select d.*,c.patient_id as id_m,c.result as r_m from
(select a.*,b.patient_id as id_f,b.result as r_f from
( select substr(a.family_id,1,4) as fid,b.* from denver_person a,
luminex b
where a.id=b.patient_id
Shujun Huang wrote:
RENCENTLY I RAN INTO THIS ERROR CODE 25P01 WHICH IS NO ACTIVE SQL
TRNASACTION. THE POSTMASTER IS RUNNING OK. THIS HAPPENED AFTER WE UPGRADED
FROM 7.4.6 TO 7.4.7.
ANY INSERT/UPDATE QUERY RUNS OK, A SIMPLE RETRIEVE QUERY IS ALSO RUNNING OK,
ANY RETRIEVE QUERIES INVOLVE IN CURSOR
Tom Lane wrote:
Hmm, 64meg should certainly be far past where check_stack_depth will
start to complain, so there's something else going on here.
Right; if those really are the stack size limits for the crashing
backend, I guess my initial analysis must have been mistaken. But I'm
mystified as to
On Thu, 2005-02-10 at 02:37 +, Brian B. wrote:
I am loading some spam/ham data/tokens, to be used for the dspam anti-spam
software, into PostgreSQL. After a few hours of inserting and updating the
existing data, the backend crashes with a signal 10 (bus error). I am also
running an ANALYZE
On Mon, 2005-01-24 at 23:50 +0100, Pavel Stehule wrote:
FOR EACH STATEMENT trigger with plperl crash backaned. FOR EACH ROW
trigger works well.
I believe this is fixed in 8.0.0
-Neil
---(end of broadcast)---
TIP 7: don't forget to increase
On Sun, 2004-12-05 at 09:43 +, PostgreSQL Bugs List wrote:
In 8.0 RC1, because of bug in -D parsing in pg_ctl I am unable to run
postgres as service when I have space in data path - when i register it with
pg_ctl register -D C:\Program Files\PostgreSQL\data and try to run it then
it
On Tue, 2004-11-30 at 22:19 +, PostgreSQL Bugs List wrote:
This means that using a prepared statement instead of a direct query is *40*
times slower!
Yes, it's a known (documented) issue that you can get inferior query
plans using prepared statements. I don't know of an easy way to fix
On Mon, 2004-11-29 at 17:10 -0600, Michael Owens wrote:
This problem seems to be related to the .psql_history file. If I
delete the file, the problem does not occur and psql starts up fine.
However, when I run psql again (after the previous session had
generated a .psql_history file), the
On Sat, 2004-11-27 at 12:55 -0500, Tom Lane wrote:
This seems like the most appropriate answer to me; I was thinking of
doing that earlier when Fabien and I were fooling with plpgsql error
reporting, but didn't get around to it.
Attached is a patch that implements a rough draft of this (it
Neil Conway wrote:
(BTW, another thing this example exposes is that we don't issue warnings
about trivially-dead-code, such as statements in a basic block that
follow a RETURN. This would probably be also worth doing.)
Attached is a patch that implements this. Specifically, if there are any
Tom Lane wrote:
There is no ELSEIF construct.
Sure, but it would be nice to throw a syntax error rather than silently
accepting the function. Unfortunately the way PL/PgSQL's parser works
doesn't make this very easy. (BTW, I think that fixing how we do parsing
would be one of the prime
On Tue, 2004-11-16 at 21:13 +0100, Magnus Hagander wrote:
Upon reviewing this patch, I notice this horrible line slipped into the
patch earlier up (in the #ifdef WIN32 section):
+ printf(uhh\n);fflush(stdout);
Oopsie. Could you remove that, or do you want a patch to do it? :-)
On Mon, 2004-11-01 at 10:49, Martin Pitt wrote:
The current Debian package has some patches that tweak the building of
contrib modules. I think they would be interesting for other
distributions, too. Most of this stuff was contributed by users who
actually use these modules.
Thanks for
Enrico Riedel wrote:
To the setup: I use the Win32 version of PGRE SQL8. The table that I am
working with has about 1.1M records in it and is indexed on several columns.
By searching the indexed columns the DB used to be very fast. The data
retrieval used to be more or less instantaneous. In Beta
Tom Lane wrote:
Possibly we should make ALTER COLUMN strip any implicit coercions that
appear at the top level of the default expression before it adds on the
implicit coercion to the new column datatype.
That seems like a kludge. When processing a column default expression, we:
(1) Accept the
On Mon, 2004-10-25 at 00:30, Tom Lane wrote:
Not without an initdb (to have another column to put it in).
We're already requiring an initdb for beta4; if this is the right way to
fix this (and I'm not insisting that it is), then ISTM we can just push
back beta4 a few days.
And it
would
On Tue, 2004-10-19 at 10:36, Tom Lane wrote:
--disable-shared means you do not get any of the backend extensions that
come as shared libraries; this includes plpgsql (and the other PL
languages if you had tried to build 'em) as well as character set
conversions. I think the tests that failed
On Mon, 2004-10-18 at 12:55, Theodore Petrosky wrote:
I just tried the newest beta (3) and for the first
time I am getting multiple errors in 'make check'.
Can you post the regression.diffs file produced by make check (should
be in src/test/regress under the directory in which you build
On Wed, 2004-10-13 at 10:23, Fahad G. wrote:
I checked and I don't have 'readline' installed. --without-readline did the
trick, but shouldn't this be handled automatically?
This is intentional -- what's wrong with stopping? ISTM that stopping
and letting the user know what went wrong is
On Thu, 2004-10-14 at 14:02, Tom Lane wrote:
The FOR UPDATE part executes after the LIMIT part. Arguably this is a
bad thing, but I'm concerned about the compatibility issues if we change
it.
I agree backward compat is a concern, but it seems pretty clear to me
that this is not the optimal
On Fri, 2004-10-15 at 14:22, Tom Lane wrote:
Allowing FOR UPDATE in sub-selects opens a can of worms that I do not
think we'll be able to re-can (at least not without the proverbial
larger size of can).
Ah, I see. I had tried some trivial queries to determine if we supported
FOR UPDATE in
On Fri, 2004-10-15 at 15:30, Tom Lane wrote:
Au contraire: every row that gets locked will be returned to the client.
The gripe at hand is that the number of such rows may be smaller than
the client wished, because the LIMIT step is applied before we do the
FOR UPDATE step
Ah, my apologies --
On Fri, 2004-10-08 at 14:45, XceXac XbdXaa wrote:
psql:zouxian-data-bak:243910: PANIC: ERRORDATA_STACK_SIZE exceeded
psql:zouxian-data-bak:243921: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while
Tom Lane wrote:
Yeah, this has been on my to-do list for awhile...
Ah, ok. Is this something you want to handle, or should I take a look?
One question here is whether Oracle's PL/SQL has a
precedent, and if so which way does it point?
I did some limited testing of this, and it appears that
Bruce Momjian wrote:
Improved wording that doesn't telegraph, Look at me!:
Each declaration and each statement within a block is terminated by a
semicolon, though the final literalEND/literal that concludes a
function does not require one.
Patch applied.
-Neil
On Fri, 2004-10-01 at 01:11, Hussein Patni wrote:
I noticed in plpgsql that a semi colon is not always requiredafter
the END statement.
Yeah, I've noticed this as well (although it doesn't appear to be
documented). Would we gain anything by enforcing this restriction? IMHO
not a lot...
-Neil
On Fri, 2004-10-01 at 02:26, Tom Lane wrote:
EXECUTE does not set the FOUND flag.
Is there a good reason for this behavior?
-Neil
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
On Fri, 2004-10-01 at 13:46, Tom Lane wrote:
We specifically do not require a semicolon at the very end of the
function definition.
Yeah, makes sense. Attached is a doc patch. Barring any objections I'll
apply it to HEAD by end-of-day today.
-Neil
Index: doc/src/sgml/plpgsql.sgml
On Fri, 2004-10-01 at 13:39, Tom Lane wrote:
Possibly not. Can EXECUTE determine how the executed statement would
have set the flag?
At the moment, EXECUTE just feeds the string it finds to spi_execute().
We could probably hack it to figure out how to modify FOUND, but I think
it would be
Tom Lane wrote:
This isn't a division problem --- the difficulty is there's no check for
overflow in int4 multiplication. (Nor in any of the other integer
arithmetic operations, for that matter.)
It seems to me that SQL2003, Section 6.26 (numeric value expression,
General Rules, item 5) requires
On 2-May-04, at 2:05 PM, Ted Kremenek wrote:
I'm from the Stanford Metacompilation research group where we use
static analysis to find bugs.
Neat. BTW, I saw a talk last summer from Madanlal Musuvathi on some
model checking work which I believe is being done by a related group at
Stanford; it
On 23-Apr-04, at 10:37 PM, Tom Lane wrote:
We install ipcclean on all platforms whether it functions or not.
Right; my question is why we do that. What purpose does it serve to
install a script that has no hope of working on this particular
platform?
-Neil
---(end of
On 18-Mar-04, at 9:47 PM, John Muzzatti wrote:
I've downloaded and installed PostgreSQL 7.4 onto a Red Hat Linux
Advanced Server release 2.1AS (Pensacola) server.
[ ... ]
I created a database and expected to see 7.4 when I query the version;
instead it seems that the version is 7.1.3.
You have
Bruce Momjian wrote:
Yea, we probably aren't releasing any more 7.1.X releases though.
Perhaps it is worth applying to the 7.1 CVS branch, at least?
BTW, I can't really see the harm in putting out 7.1.x and 7.2.x
releases to fix compilation issues on modern systems. For example, I
believe that
Tom Lane wrote:
The harm is the developer time spent on doing so. Releasing back
versions takes nontrivial effort (witness what it took to get 7.3.6
out the door :-().
True; that said, much of this overhead is (IMHO) avoidable. There
should be little or no manual intervention needed in the
PostgreSQL Bugs List wrote:
This works fine on Linux using 7.3.4. It also worked on 7.2.x on Cygwin.
FWIW, I can reproduce this problem with CVS HEAD.
-Neil
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
Tom Lane [EMAIL PROTECTED] writes:
Kris Jurka [EMAIL PROTECTED] writes:
When the JDBC driver tries to query the information schema running against
cvs head, it gets an assertion failure.
Duplicated here, will fix.
Is it worth including some variant of this query in the regression
tests?
Okay, I've attached a patch that fixes the problem for me. The problem
turned out to be pretty simple: the PostgreSQL code (both backend and
frontend SSL support) was calling SSL_get_peer_certificate() without
properly free'ing its return value.
I haven't actually confirmed the backend memory
Neil Conway [EMAIL PROTECTED] writes:
I can verify this locally. Unfortunately, my copy of valgrind doesn't
seem to be picking up the debugging symbols for OpenSSL
Ok, some progress. I installed a development snapshot of OpenSSL, and
confirmed that the problem still occurs there. The full
PostgreSQL Bugs List [EMAIL PROTECTED] writes:
I have installed the Postgres by the procedure by. it got installed
at /usr/local/pgsql/bin but, when i re-start the system. the
postgres service starts from /usr/bin.
what shall i do i have tried it by editing the
/etc/rc.d/inid.d /
Josh Berkus [EMAIL PROTECTED] writes:
Summary: attempting to connect via MD5 authentication as a user
who has no password triggers a core dump of Postmaster.
[...]
Core dump file is available.
Can you post a stacktrace? (Building the postmaster with debugging
symbols first would be
Olaf Hartmann [EMAIL PROTECTED] writes:
We expirience a memory leak with every connection when using an SSL
encrypted TCP connection to connect a postgres database.
I can verify this locally. Unfortunately, my copy of valgrind doesn't
seem to be picking up the debugging symbols for OpenSSL,
Margus Väli [EMAIL PROTECTED] writes:
COPY command tries to create a buffer too large in size when the
file copied is larger than about 500 bytes.
Can anyone else reproduce this? I did the following with a fairly
recent CVS snapshot:
1. Copied the supplied text data to a file, fixed up the
Steve Thames [EMAIL PROTECTED] writes:
The SQL command:
SELECT last FROM table WHERE symbol='Symbol' AND expmoyr='Mmm-YY' ORDER BY
qdate DESC LIMIT 1;
This query works fine when there is more than one record meeting the
criteria. When there is only 1, the query locks and no result is
Alex Albarracin [EMAIL PROTECTED] writes:
Hello, i have a problem related to the partition memory where
postgres is installed, this has increased so much that the partition
is full and postgres can not start up. The message postmaster sends
when i want to restart is insuficient disk space. Do
Tom Lane [EMAIL PROTECTED] writes:
Neil Conway [EMAIL PROTECTED] writes:
If not, we needn't worry about it, IMHO. But if there are, I can
take a look at producing a low-risk version of this changed for
application to REL7_3_STABLE.
Go for it.
Just FYI, I'm really busy with various other
Theodore Petrosky [EMAIL PROTECTED] writes:
After about two hours of hunting pecking and anything
else I found where you control this in OSX 10.3
you must edit the /etc/rc file.
/System/Library/StartupItems/SystemTuning/SystemTuning
does nothing
Should we update the documentation's
The pgsql-bugs mailing list is intended for bug reports about
PostgreSQL, not support requests.
lucas sultanum [EMAIL PROTECTED] writes:
I have been reading a lot about PostGreSQL but until now I haven't
found anything stating if the PostGreSQL database has any locking
mechanism. If so, could
Thomas Erskine [EMAIL PROTECTED] writes:
A before trigger doesn't always fire. If a column being inserted into is
too small for the incoming data, psql complains:
ERROR: value too long for type ...
without giving the trigger procedure a chance to deal with it.
I believe this is a
Przemysaw [EMAIL PROTECTED] writes:
Hello
I dont know is this a bug but when I use COPY to load data into table
sequence of the primary key in this table have always start value =
1.
Doesn't sound like a bug. If the input data for COPY does not include
PK values, you should not include the PK
Tom Lane [EMAIL PROTECTED] writes:
Paul Tillotson [EMAIL PROTECTED] writes:
pg_dumpall does not save all access control permissions on a database.
(This is true for at least the CREATE permission.)
This is fixed as of 7.4.
Is this a candidate for being back-patched to 7_3_STABLE? IMHO it
Tom Lane [EMAIL PROTECTED] writes:
Well, it was done as part of a significant set of changes to
pg_dumpall:
Are there plans for a 7.3.5 release? If not, we needn't worry about
it, IMHO. But if there are, I can take a look at producing a low-risk
version of this changed for application to
Gaetano Mendola [EMAIL PROTECTED] writes:
I don't know how the check for the data integrity is implemented but if
is a trigger
It isn't -- trigger firing order is irrelevant to the original
question.
1) Create table
2) create a before insert trigger: trigger_a
3) create a before insert
Gaetano Mendola [EMAIL PROTECTED] writes:
Well, it is. If the data integrity was done with a system trigger
created at table creation time the firing order is relevant.
Right, but the data integrity check is _not_ done via a system
trigger. Hence, trigger firing order is irrelevant to the
On Fri, 2003-10-31 at 12:25, Nitz wrote:
You were right, the volume of the data changes the optimizer's
willingness to use indexes.
AFAICS, the optimizer seems to be making exactly the right guesses for
the production data -- i.e. there's no problem/bug.
Another funny thing though... I
On Wed, 2003-10-15 at 02:08, Nayib Kiuhan wrote:
In versions before 7.4beta3 I use to have tables with
date timestamp DEFAULT 'now'
It use to works properly, placing the actual date at the moment a new
record was inserted. Now it always have the same date which correspond
to the date at
On Wed, 2003-10-15 at 13:29, Nayib Kiuhan wrote:
It is a good idea to through out an error during the table creation if
the format is not as indicated (now()), because when I created my
tables with the old format, it did not show any problem
I agree that this kind of silent
1 - 100 of 123 matches
Mail list logo
