On Thu, 2005-13-10 at 12:17 -0400, Andrew Dunstan wrote:
I don't agree that we need to force one spelling of common words when
many dictionaries recognise the validity of variant spellings.
There is obviously no need to force the use of one spelling variant or
another. However, I think it is
On Tue, 2005-11-10 at 18:36 -0700, David Fetter wrote:
Examples of each and how they'd break would be good.
Is that needed? Seems like overkill to me.
-Neil
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
On Tue, 2005-11-10 at 18:55 -0700, David Fetter wrote:
IMHO, yes, and no, respectively. If there's an example, there's fewer
frustrated people pestering lists about it.
There is something to be said for brevity: spending a lot of prose on an
example of an obscure problem means the
On Tue, 2005-04-10 at 09:41 -0700, David Fetter wrote:
Could you apply this to the 8.0 docs, too?
Applied, with fixes.
-Neil
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail
On Mon, 2005-03-10 at 12:28 -0400, Qingqing Zhou wrote:
Ooops, this wording change is inconsistent with Log_connections, so I
reverted it. Updated patch is attached.
Other inconsistencies:
- the patch prints a trailing comma when remote-port is the empty
string
- the patch separates the
On Mon, 2005-03-10 at 00:37 -0400, Qingqing Zhou wrote:
Trivial patch to cleanup log_disconnections() function.
Why does the patch change behavior when
- port-remote_port is the empty string
- or, when end.tv_sec is negative
I'm not adamant that the old behavior is better, but I'd like to see
On Fri, 2005-23-09 at 00:14 -0700, David Fetter wrote:
Yes. Please find enclosed round 2 of the patch. It implements
multiple -n's and multiple -t's, although I think it's broken for
multiple -n's with no -t's.
BTW, have you read the (extensive) prior discussion of this topic? For
example,
A few minor comments are below. This is for 8.2, right?
On Tue, 2005-20-09 at 08:51 -0700, David Fetter wrote:
/* obsolete as of 7.3: */
static Oidg_last_builtin_oid; /* value of the last builtin oid
*/
! static char **selectTableNames = NULL;/* name(s) of
specified
On Tue, 2005-20-09 at 11:33 -0700, David Fetter wrote:
I am hoping to make a case for inclusion in 8.1. The code is
completely isolated in one command and does not affect anyone who
does not use the new features.
On those grounds we could include a lot of new features during the 8.1
beta
Peter Eisentraut wrote:
Moreover, I don't agree with the premise.
This patch is blocking other work. If you still object to it, can you
elaborate why?
Otherwise I'll apply it this evening (EST).
-Neil
---(end of broadcast)---
TIP 3: Have you
Seth Robertson wrote:
In order to support some automation, I needed the ability to pull out
subsets of postgres tables in a format which could be loaded into
other postgres databases.
One alternative would be using CREATE TABLE AS to create a separate
table containing the desired subset, and
Michael Fuhr wrote:
The synopsis for SPI_getbinval() shows the third argument being
colnumber but in the Arguments section it appears as rownumber.
This patch corrects that.
Thanks for the patch -- applied to HEAD, 8.0, and 7.4
-Neil
---(end of
Neil Conway wrote:
This patch is blocking other work [...]
Otherwise I'll apply it this evening (EST).
Applied.
-Neil
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
This patch moves the documentation of the configuration parameters into
a separate chapter; it was formerly a section in the Server Run-time
Environment chapter. This is per earlier discussion.
Because of the volume of SGML being moved, the patch is fairly large
(~360KB uncompressed), but
Peter Eisentraut wrote:
We are in beta; the time for major reorganizations has passed.
This is not a major reorganization.
In any case, the primary reason to avoid major reorganizations during
beta is the risk of regressions, which does not really apply here.
Moreover, I don't agree with
Tom Lane wrote:
As far as I could tell by eyeball, you are simply moving the section out
to be a separate chapter and a separate file, without changing any text?
Sorry, I should have noted that explicitly in my original email. The
vast majority of the patch is just moving the same text to a
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list
It was agreed earlier that this should be saved for 8.2, I believe.
-Neil
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore
Simon Riggs wrote:
I thought you removed that in February? Or is my memory playing tricks?
Not I -- Tom removed src/backend/storage/smgr/mm.c in February of '04,
but evidently forgot to remove the associated LWLock.
-Neil
---(end of
Tom Lane wrote:
The other spots seem to be OK. Thanks for the report and fix!
Woops, my apologies for introducing the bug. In general I think it's
worth removing explicit initialization of out parameters unless that
initialization is actually needed. I thought I had checked that
Tom Lane wrote:
I think the reason is that it's both an input and an output parameter,
to handle the case where the cast function returns NULL.
The only reference to `isnull' in the body of exec_cast_value() is:
if (!*isnull)
{
/* ... */
}
i.e. it is never referenced again, let alone
Tom Lane wrote:
Those cases are for places where the spec defines similar cases under
the error classes SQL Routine Exception and External Routine Exception.
You can blame me for having assumed that plpgsql didn't need to
distinguish these cases.
Well, in and of itself, I agree it is probably
Tom Lane wrote:
[ scratches head... ] Did this code change recently? It's a tad hard
to believe that such a thing could have gone unnoticed for long.
Seems the problem was introduced here:
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_dump/pg_backup_db.c.diff?r1=1.58;r2=1.59
Tom Lane wrote:
I'd go with reverting it to using PQdb, myself.
Fair enough; reverted to using PQdb(), and applied to HEAD and
REL8_0_STABLE.
-Neil
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Neil Conway wrote:
Not at the moment. I believe we have agreed that it would be better to
remove the concept of exception variables and just use strings, but I
haven't implemented this yet.
BTW, one minor annoyance I noticed: a builtin condition name can
actually map to multiple SQLSTATE
On 7/19/05 8:11 AM, Titus von Boxberg [EMAIL PROTECTED] wrote:
As for NFIELDS, I don't think we need it -- you can always measure the
length of the FIELDNAMES array.
I would like to leave it there. As far as I can see it's much faster
than other builtins for evaluating array dimensions and I
Titus von Boxberg wrote:
What do you mean by right syntax. There are hundreds of examples
in programming languages where a small syntactic difference leads to
totally different semantics.
Well, I'm just not happy that foo.bar means something completely
different than foo%bar -- foo%bar isn't
Titus von Boxberg wrote:
Having read the FAQ, it's not clear to me, where the patches go (and when)
that I would send into this list.
These are my open questions:
Are the patches applied to HEAD?
It depends on the patch. New features are almost exclusively only
applied to HEAD, whereas
Titus von Boxberg wrote:
With the following patch it's possible to
- extract all field names of a record into an array
- extract field count of a record
- address a single field of a record with a variable
containing the field name (additional to the usual record.fieldname
notation where the
Simon Riggs wrote:
This doc patch replaces all inappropriate references to SQL:1999 when it
is used as if it were the latest (and/or still valid) SQL standard.
Applied, thanks.
-Neil
---(end of broadcast)---
TIP 4: Have you searched our list
Ilia Kantor wrote:
Immutability is obvious, because xml procession result depends on the
document and request solely.
Thanks, applied with some tweaks. I've attached the patch I applied.
-Neil
Index: contrib/xml2/pgxml.sql.in
===
Peter Eisentraut wrote:
I think it would be less confusing in these cases to simply write
This is conforming to the SQL standard. and then mention in the
appendix that we consider SQL:2003 to be the baseline.
How would this help? ISTM you are just suggesting we replace conforming
to SQL:2003
Simon Riggs wrote:
The main point is that SQL:1999 no longer has any validity as a standard
and has been wholly superceded by SQL:2003. SQL:1999 has interest only
for historical reasons, for those who care when a particular feature was
introduced.
Right; I guess the question is whether we
David Fetter wrote:
On Tue, Jul 12, 2005 at 12:21:29PM -0700, David Fetter wrote:
Folks,
Please find enclosed document patches for PL/Perl features recently
introduced in CVS TIP. These include:
return_next
returning PostgreSQL arrays
spi_query/spi_fetchrow
use strict
Cheers,
D
Oops.
Bruce Momjian wrote:
Where are we on this patch? Is there something to apply?
Not at the moment. I believe we have agreed that it would be better to
remove the concept of exception variables and just use strings, but I
haven't implemented this yet. I'm happy to do that, but I might not get
[EMAIL PROTECTED] wrote:
Thank you, that would answer the question. There is no also about it;
it's exactly what I was asking all along. The conclusive answer for us
would be in the C89 standard of course, where (at least in the draft that
Neil quoted) I haven't been able to find anything like
Pavel Stehule wrote:
BEGIN
EXCEPTION WHEN * THEN
equvalent rules for raise have to be in *
is true?
I'm sorry, but I'm still not sure what you mean.
-Neil
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore
Gavin Sherry wrote:
This patch removes dead code from redo_dbase().
Barring any objections, I'll apply this tomorrow.
I've removed XLOG_DBASE_CREATE_OLD and XLOG_DBASE_DROP_OLD from the header
as well but have not changed the values of XLOG_DBASE_CREATE and
XLOG_DBASE_DROP so as to avoid the
Michael Fuhr wrote:
This patch updates the DDL for contrib/pgcrypto to create all
functions as STRICT, and all functions except gen_salt() as IMMUTABLE.
gen_salt() is VOLATILE.
Barring any objections, I'll apply this tomorrow.
-Neil
---(end of
Gavin Sherry wrote:
This patch removes dead code from redo_dbase(). The code processes
CREATE/DROP DATABASE recovery records which are of types
XLOG_DBASE_CREATE_OLD and XLOG_DBASE_DROP_OLD. We do not create such
records.
Applied with additional fixes (you forgot to remove the reference to the
Michael Fuhr wrote:
This patch updates the DDL for contrib/pgcrypto to create all
functions as STRICT, and all functions except gen_salt() as IMMUTABLE.
gen_salt() is VOLATILE.
Applied, thanks.
-Neil
---(end of broadcast)---
TIP 9: In versions
Neil Conway wrote:
Ah, I see. I would be content to allow opt_sqlstate to be either a
string literal, a T_WORD (predefined error condition), or a TEXT
variable. If users need to throw a sqlstate that is derived from a SQL
expression, they can always assign to a TEXT variable and then specify
Pavel Stehule wrote:
ok, but don't forget, please, on exception part.
What do you mean?
-Neil
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so
Per EDB's Coverity analysis, runtimeKeyInfo is only non-NULL if
econtext is also non-NULL, so we can eliminate a conditional on the
former by moving it inside an if block for the latter. Per discussion
of earlier similar changes, this is not for performance reasons but for
code clarity.
[EMAIL PROTECTED] wrote:
(a) the C standard has added a sequence point between the arguments in a
function call, which AFAIK wasn't there before, or the sequence point was
there all along (and the compiler implements it);
Per C99 6.5.2.2.10, a sequence point occurs between the evaluation of
Tom Lane wrote:
- should work for UPDATE and DELETE too
And probably INSERT ... SELECT as well.
-Neil
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Does anyone know what the situation is in C89, or whatever the applicable
standard is?
[ *looks* ]
The text is the same in both versions:
http://dev.unicals.com/papers/c89-draft.html#3.3.2.2
The order of evaluation of the function designator, the arguments, and
[EMAIL PROTECTED] wrote:
That is pretty much what I remember hearing at the time.
A well-known way to trigger undefined behaviour is x++=x++; because
there is no sequence point between the two side effects. Try it: gcc will
give you a stern warning. Given that there is no sequence point
Tom Lane wrote:
I think this is all irrelevant language-lawyering; jtv spotted the true
problem which is that we do not protect errno during the *first* call of
libpq_gettext.
I think you're missing the point. Obviously the current code is wrong,
the debate is over the best way to fix it.
Pavel Stehule wrote:
Per small recent discussion I corrected patch user's exception.
Attached is a revised patch. I haven't looked at the documentation
changes yet (more work is needed I believe) or some of the error message
text.
I was originally hoping to make exception variables a
This patch fixes the following issues in ECPGstore_input():
- strlen() was invoked on the NULL pointer for the first iteration of
the loop (line 875, 923, 966, 1009)
- `nval' is freed for every iteration of the loop at 864, but only
initialized once outside the loop, resulting in potential
Tom Lane wrote:
I think it is a bad idea, if not actually impossible, to have an
expression for sqlstate with no separating syntax before the 'fmt';
especially not if you'd like to also allow an expression for the 'fmt'.
I don't actually see much of a need to allow 'fmt' to be an expression,
Tom Lane wrote:
RAISE NOTICE '12' !! '345', ...
Is !! an infix operator (using both strings as arguments) or a postfix
operator (in which case '345' is the format)?
Ah, I see. I would be content to allow opt_sqlstate to be either a
string literal, a T_WORD (predefined error
Bruce Momjian wrote:
+ /*
+ * Return the length of a datum, possibly compressed
+ */
+ Datum
+ pg_column_size(PG_FUNCTION_ARGS)
+ {
+ Datum value = PG_GETARG_DATUM(0);
+ int result;
+
+ /* fn_extra stores the fixed column length, or
Mark Kirkwood wrote:
I didn't performance test it, but the idea of hammering the catalogs for
each value to be processed seemed a bad thing.
Well, the syscache already sits in front of the catalogs themselves. I'd
be curious to see what the performance difference actually is...
-Neil
Andrew Dunstan wrote:
In the course of looking into Larry's buildfarm woes, I found that
Unixware needs this patch on HEAD to build correctly
Thanks -- I already applied an equivalent fix to HEAD.
-Neil
---(end of broadcast)---
TIP 6: Have you
Marko Kreen wrote:
Please use following updated patch instead.
It implements utf8 conversion, fixes couple of bugs and has
many code and comment cleanups.
The regression tests don't pass on my box. With the default Makefile,
there are a lot of errors WRT no strong random source. After
Pavel Stehule wrote:
Per small recent discussion I corrected patch user's exception.
I'll review and apply this in the next day or so.
Next ToDo (needs discussion):
+ Optional message in raise stmt for user's or system exception
raise exception division_by_zero;
+ Possibility
This patch silences a GCC 4.0 warning about a potentially-uninitialized
variable in pl_comp.c, and makes some minor associated cleanups. Barring
any objections I'll apply this to HEAD tomorrow.
-Neil
Index: src/pl/plpgsql/src/pl_comp.c
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list
That is not the latest version of Marko's patch. But in any case, the
patch is not yet ready for application:
http://archives.postgresql.org/pgsql-patches/2005-07/msg00077.php
-Neil
Bruce Momjian wrote:
Patch applied. Thanks.
Should either or both of these patches be applied to back branches?
-Neil
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Hi,
BTW, the Postgres convention is to submit patches in context diff format
(diff -c).
Satoshi Nagayasu wrote:
+ while (HeapTupleIsValid(tuple = systable_getnext(tgscan)))
+ {
+ HeapTuple newtup = heap_copytuple(tuple);
+ Form_pg_trigger pg_trigger =
Attached is a trivial improvement to ecpg's pgtypeslib: (1) `pstr' must
be non-NULL in this function, so no need to check for it (2) we should
check the return value of pgtypes_strdup(). Patch from Eric Astor at
EDB, with slight cleanup by myself, to fix a Coverity report.
Barring any
This patch adds some missing error handling to PGTYPESnumeric_div() in
ecpg's pgtypeslib: (1) we need to check the return value of sub_abs()
(2) we need to check the return value of 4 calls to digitbuf_alloc().
Per Coverity static analysis by EDB.
Barring any objections I'll apply this to CVS
Neil Conway wrote:
This patch adds some missing error handling to PGTYPESnumeric_div() in
ecpg's pgtypeslib: (1) we need to check the return value of sub_abs()
(2) we need to check the return value of 4 calls to digitbuf_alloc().
Applied.
-Neil
---(end of broadcast
Neil Conway wrote:
Attached is a trivial improvement to ecpg's pgtypeslib: (1) `pstr' must
be non-NULL in this function, so no need to check for it (2) we should
check the return value of pgtypes_strdup(). Patch from Eric Astor at
EDB, with slight cleanup by myself, to fix a Coverity report
The attached patch fixes a theoretical memory leak in libpq: if the
second malloc() fails due to OOM, the memory returned by the first
(successful) malloc() will be leaked.
Barring any objections I'll apply this tomorrow.
Per report from EnterpriseDB's Coverity analysis.
-Neil
Index:
Tom Lane wrote:
Since both allocations are only transient within this routine, there's
a simpler more effective solution, which is to only do one malloc in
the first place
Yeah, true. Attached is a revised patch -- committed to HEAD.
-Neil
Index: src/interfaces/libpq/fe-auth.c
Tom Lane wrote:
Right. So do we care whether the collector has the right number?
Not at present; n_backends is not read/written by the stats collector
itself, it is just in the hash table for the convenience of backends who
read in the stats file.
Or should we push the responsibility for
Tom Lane wrote:
I'm still missing what the exact bug fix is here.
The bug is:
- a backend starts up and sends the collector a BESTART message. For the
sake of clarity, suppose that the backend is the first and only backend
connected to its database.
- the stats collector receives the
Magnus Hagander wrote:
This patch removes Kerberos version 4 support from the backend and
libpq.
Applied, thanks.
Bruce, can you mark the Remove krb4 TODO item as finished? Thanks.
-Neil
---(end of broadcast)---
TIP 6: Have you searched our
Petr Jelínek wrote:
I am bit confused now because I am no really sure if it's intended to be
this way or not - 8.0 behaviour was to report numbackends when stats
were on, now it reports numbackends when stats_row_level is true.
Yeah, this is a bug. Attached is a fix. I'll apply this to HEAD
Tom Lane wrote:
I looked at this but did not actually see the code path that requires
forcing creation of the per-DB entry right at this spot. The HASH_FIND
calls for this hashtable seem to all happen on the backend side not the
collector side. Can you explain why we need this?
Yeah, I
Alvaro Herrera wrote:
This trivial patch removes an unused variable, this time in
utils/init/postinit.c
Applied, thanks.
-Neil
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Pavel Stehule wrote:
Attached patch provide continue stmt in plpgsql language. Continue stmt
start new step in any loop stmt. If stmt continue is in begin end block,
then find first outer loop (per recent discussion).
Attached is a revised patch. I didn't see anything major that needed to
Magnus Hagander wrote:
This patch removes Kerberos version 4 support from the backend and
libpq.
I'll apply this later today, barring any objections.
-Neil
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister
Tom Lane wrote:
I think mostly what you are doing here is causing code drift from the
upstream zic code. I don't think that's a very good idea, since we
do need to be able to track and apply bug fixes from them from time
to time ...
Why run pgindent on the timezone code, then? That seems
Tom Lane wrote:
Well, it's certainly hopeless to expect patch to fix it :-(. But the
further the code drifts the harder it gets to compare manually.
Sure, but I don't see how removing a few register qualifiers and so
forth is going to make the slightest difference to a manual comparison.
If
The Coverity tool picked up some rather bizarre code in _tarGetHeader in
pg_backup_tar.c:
(1) The code doesn't initialize `sum', so the initial does the checksum
match? test is wrong.
(2) The loop that is intended to check for a null block just checks
the first byte of the tar block 512
This patch makes various cosmetic improvements to the timezone code:
remove the use of the register qualifier, make some function declaration
syntax a bit more consistent, etc.
I'll apply this later today, barring any objections.
-Neil
Index: src/timezone/ialloc.c
Neil Conway wrote:
Per earlier discussion on pgsql-hackers[1], this patch changes the
implementation of hash join to attempt to avoid redundant work if either
of the join relations are empty.
Applied.
-Neil
---(end of broadcast)---
TIP 6: Have
Neil Conway wrote:
This makes a few improvements to PL/PgSQL's ability to dump the parse
tree of a compiled function
Applied.
-Neil
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Tom Lane wrote:
That doesn't bother me either, seeing that an undefined variable isn't
detected at compile time anywhere else. However, fixing the SQLSTATE
tests by removing them doesn't seem like a great solution ...
Yeah, true, I can just invoke the function to trigger the undefined
Tom Lane wrote:
But you had mentioned wanting to look at reducing overhead by using
exec_eval_expr(); were you intending to do that before committing?
I'm a bit busy with other matters at the moment, so I'll probably look
at it later. One question is whether we should make use of
Per discussion on -hackers, this patch changes psql's expanded output
mode to only affect the presentation of normal query results, not the
output of psql slash commands. Documentation updated. I also made some
unrelated minor psql cleanup.
Barring any objections I'll apply this later today
This makes a few improvements to PL/PgSQL's ability to dump the parse
tree of a compiled function (via #option dump, which is currently
undocumented):
- functions - function's
- dump INTO target for EXECUTE
- don't dump ELSE clause for IF statements if the ELSE is empty (since
we have an
Neil Conway wrote:
This patch removes some old code from libpq that implements a URI-like
syntax for database connection parameters. It has been inside an #ifdef
NOT_USED block since 2001 or so and is marked as broken, so I don't
think it is likely to be rehabilitated any time soon.
Applied
Neil Conway wrote:
Attached is a patch that implements this. This adds checking for most of
the call sites of strdup(), malloc(), PQmakeEmptyPGresult(),
pqResultAlloc(), and pqResultStrdup() in libpq. Barring any objections,
I'll apply this to HEAD tomorrow.
Applied. Thanks for the report
Tom Lane wrote:
A nonterminal that is not intended to represent any real input, ever,
is just plain weird.
If you say so... PL/PgSQL already uses such a beast, though: the lno
nonterminal, for example.
Not at all. The right way to do this, I think, is for the mid-rule
action to palloc the
Tom Lane wrote:
I still find the grammar changes to be an ugly kluge --- it should be
possible to do this without introducing bogus nonterminals.
The scope-local variables need to be added to the namespace by the time
that we parse the WHEN clauses. I can see two ways to do that: adding a
If you're busy, I can clean this up and apply it.
I wonder if it would be better to have lastval() return the last value
returned by nextval() or setval() for the current session, regardless of
any intervening DROP SEQUENCE commands. This would simplify the
implementation (we can just store
Abhijit Menon-Sen wrote:
Could someone who likes this idea please write the documentation for it?
Dennis' original patch includes documentation updates and a description
of lastval():
http://archives.postgresql.org/pgsql-patches/2005-05/msg00059.php
I'd really like to see a concise,
Tom Lane wrote:
This definition is OK with me ... so long as it still includes the
phrase an error occurs if no nextval or setval has occurred in the
current session. However it seemed that a number of people asking
for the feature wanted some-random-default to be returned instead.
Right --
Tom Lane wrote:
I agree with that --- consider that you couldn't actually promise that
the sequence hadn't been dropped by the time the answer is returned,
anyway, unless you take out a lock on the sequence first. Which doesn't
seem like a behavior that is wanted here.
The only objection I
Bruce Momjian wrote:
Could we do your NOLOGGING automatically in COPY if we test to see if
anyone else is connected to our current database?
That seems pretty fragile -- what happens if someone connects after the
COPY has started? Considering that many COPY operations can take many
minutes
On Thu, 2005-06-02 at 00:53 -0400, Alon Goldshuv wrote:
My thoughts were -- see how the responses are, and if people think
that this is a better way to go than replace the COPY parsing logic to
the new one.
If the new approach to parsing can handle all the cases that the old
approach can
On Sun, 2005-05-22 at 21:25 +0530, Abhijit Menon-Sen wrote:
I have attached the following seven patches to address this problem:
Does anyone with the skills to review this (i.e. someone other than me)
have any comments on this patch?
Otherwise I'll apply it in a day or two.
-Neil
On Sun, 2005-05-08 at 19:00 +0200, Dennis Bjorklund wrote:
Here is a small patch that implements a function lastval() that
works just like currval() except that it give the current
value of the last sequence used by nextval().
Have you had a chance to respin this patch per my earlier comments
Pavel Stehule wrote:
http://www.techonthenet.com/oracle/functions/add_months.htm
http://www.techonthenet.com/oracle/functions/last_day.htm
http://www.techonthenet.com/oracle/functions/next_day.htm
http://www.techonthenet.com/oracle/functions/months_between.htm
Are these functions useful enough
On Wed, 2005-06-01 at 17:08 -0700, Mary Edie Meredith wrote:
I know I'm late to this discussion, and I haven't made it all the way
through this thread to see if your questions on Linux writes were
resolved. If you are still interested, I recommend read a very good
one page description of
On Wed, 2005-06-01 at 16:34 -0700, Alon Goldshuv wrote:
1) The patch includes 2 parallel parsing code paths. One is the regular COPY
path that we all know, and the other is the improved one that I wrote. This
is only temporary, as there is a lot of code duplication
Right; I really dislike the
301 - 400 of 833 matches
Mail list logo
