Any objection if I rework this function to meet SQL92 and fix the bug?
I don't object.
Or is the SQL92 part not desirable because it breaks backward
compatability?
I don't think so.
In any case, can the #ifdef MULTIBYTE's be removed now in favor of a
test for encoding max length?
Hang on - I _can't_ fix the function defiition - it returns a bool and
that's why it's failing. I can't have it returning a void because it's not
possible. Check list of all other excluded functions as well...
Chris
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
To: Christopher
Ah doh - I thought it was catching it returning a boolean. I'll fix and
resubmit.
Chris
- Original Message -
From: Joe Conway [EMAIL PROTECTED]
To: Christopher Kings-Lynne [EMAIL PROTECTED]
Cc: Hackers [EMAIL PROTECTED]
Sent: Friday, August 09, 2002 11:26 PM
Subject: Re: [HACKERS]
than to do:
CREATE TYPE some_arbitrary_name AS (f1 int, f2 text);
CREATE FUNCTION foo() RETURNS SETOF some_arbitrary_name;
But I admit it is only a nice-to-have, not a need-to-have.
How do others feel? Do we want to be able to implicitly create a
composite type during function
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Ah doh - I thought it was catching it returning a boolean. I'll fix and
resubmit.
Unfortunately I don't believe Joe's theory --- an OID conflict between
pg_proc and pg_type shouldn't matter, and in any case the particular
sanity check that's
On Sat, 2002-08-10 at 00:25, Mark Kirkwood wrote:
Ralph Graulich wrote:
Hi,
just my two cents worth: I like having the files sized in a way I can
handle them easily with any UNIX tool on nearly any system. No matter
wether I want to cp, tar, dump, dd, cat or gzip the file: Just keep it
Tom Lane wrote:
Unfortunately I don't believe Joe's theory --- an OID conflict between
pg_proc and pg_type shouldn't matter, and in any case the particular
sanity check that's failing is not looking at pg_type:
I guess I should know better than to jump to a conclusion. But I *was*
under the
Joe Conway [EMAIL PROTECTED] writes:
I guess I should know better than to jump to a conclusion. But I *was*
under the impression we were supposed to use the unused_oids script to
get a unique oid for a new function.
Right, we do still insist that all hand-assigned OIDs be distinct, but
that
Patch applied. Thanks.
---
Oleg Bartunov wrote:
Please, apply patch for contrib/intarray (current CVS)
Changes:
August 6, 2002
1. Reworked patch from Andrey Oktyabrski ([EMAIL PROTECTED]) with
Patch applied. Thanks.
---
Teodor Sigaev wrote:
Fixed very stupid but important bug: mixing calls of some founctions from
contrib/tsearch and contrib/ltree :)
--
Teodor Sigaev
[EMAIL PROTECTED]
[
On 9 Aug 2002, Scott Shattuck wrote:
Hi,
We recently put up a new 7.2.1 installation on Solaris 8 that serves a
24x7 e-commerce site. The system seems to run pretty well most of the
time but we see a consistent form of performance anomaly.
Watching pg_stat_activity the system spends
Patch applied. Thanks.
---
Teodor Sigaev wrote:
The patch solves this problem, I hope...
Christopher Kings-Lynne wrote:
I'm still getting ltree failures on 64bit freebsd:
sed
I intend to make 'serial' and 'serial8' domains of the int4 and int8
datatypes. Now they're regular types and columns in \d will be marked
as such. This leaves analyze.c to create the defaults but no longer
will it be doing any datatype conversions.
pg_dump and psql will be taught to ignore
P src/interfaces/libpqxx/configure.ac
cvs server: Updating src/interfaces/libpqxx/config
U src/interfaces/libpqxx/config/.cvsignore
cvs server: Updating src/interfaces/libpqxx/debian
cvs server: failed to create lock directory for
`/projects/cvsroot/interfaces/libpqxx/debian'
On Sat, Aug 10, 2002 at 06:05:27PM -0400, Rod Taylor wrote:
P src/interfaces/libpqxx/configure.ac
cvs server: Updating src/interfaces/libpqxx/config
U src/interfaces/libpqxx/config/.cvsignore
cvs server: Updating src/interfaces/libpqxx/debian
cvs server: failed to create lock directory for
(/projects/cvsroot/interfaces/libpqxx/debian/#cvs.lock): Permission
denied
cvs server: failed to obtain dir lock in repository
`/projects/cvsroot/interfaces/libpqxx/debian'
cvs [server aborted]: read lock failed - giving up
I only just added that directory, so chances are you were
OK, seems we have not come to a decision yet on this.
Do we have agreement to increate FUNC_MAX_ARGS to 32?
NAMEDATALEN will be 64 or 128 in 7.3. At this point, we better decide
which one we prefer.
The conservative approach would be to go for 64 and perhaps increase it
again in 7.4 after we
Bruce Momjian [EMAIL PROTECTED] writes:
Do we have agreement to increate FUNC_MAX_ARGS to 32?
I believe so.
NAMEDATALEN will be 64 or 128 in 7.3. At this point, we better decide
which one we prefer.
The conservative approach would be to go for 64 and perhaps increase it
again in 7.4 after
Bruce Momjian wrote:
OK, seems we have not come to a decision yet on this.
Do we have agreement to increate FUNC_MAX_ARGS to 32?
NAMEDATALEN will be 64 or 128 in 7.3. At this point, we better decide
which one we prefer.
The conservative approach would be to go for 64 and perhaps
I would like to address this email.
Lamar is mentioning that it is unfair to remove a feature without
warning.
Let me give a little history. The secondary password file was created
at a time when we didn't encrypt with random salt over the wire, and we
had people who wanted to share their
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Greg Copeland wrote:
Checking
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Greg Copeland wrote:
Checking
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Greg Copeland wrote:
Checking
23 matches
Mail list logo
