Tom Lane wrote:
Oleg Bartunov [EMAIL PROTECTED] writes:
seems rtree doesn't ignore NULL ?
Hm, maybe not. There are explicit tests to ignore null inputs in hash
indexes (hash/hash.c), and I'd just sort of assumed that rtree and gist
do the same.
FWIW, your example doesn't seem to
Oleg Bartunov wrote:
We finished (cross fingers) our changes in GiST code for 7.0.3
Are tha patches for 7.0.3 already available ?
and in next 2 days we plan to send patches for upcoming 7.1 release.
Isn't this too late ? What else we need to submit ?
We have int4array contribution package
select * from table where col = function() ;
(2) "function()" returns a number of values that are independent of the
query. Postgres should be able to optimize this to be: "select * from
table where col in (val1, val2, val3, ..valn)." I guess Postgres can
loop until done, using the isDone
Not sure what to do about this. If you had actually typed 2^64-1040,
it would be appropriate for the code to reject it. But I hadn't
realized that the extra check would introduce a discrepancy between
32- and 64-bit machines for negative inputs. Maybe it'd be
better just
to delete the
VACUUM ANALYZE after the INSERTs made no performance difference at all,
which is good since no other modern database requires anything to be done
to improve performance after a large number of INSERTs. (i can understand
why COPY would need it, but not INSERT.)
I know of no DB that
On Thu, 21 Dec 2000, Hannu Krosing wrote:
Date: Thu, 21 Dec 2000 11:12:41 +0200
From: Hannu Krosing [EMAIL PROTECTED]
To: Oleg Bartunov [EMAIL PROTECTED]
Cc: Tom Lane [EMAIL PROTECTED], Bruce Momjian [EMAIL PROTECTED],
PostgreSQL-development [EMAIL PROTECTED]
Subject: Re: [HACKERS] Who
* Tom Lane [EMAIL PROTECTED] [001220 13:02]:
Paul A Vixie [EMAIL PROTECTED] writes:
cisco IOS just won't take 10/8 and insists on 10.0.0.0/8. you will never,
ever go wrong if you try to use 10.0.0.0/8, since everything that understands
CIDR understands that. 10/8 is a pleasant-appearing
Zeugswetter Andreas SB wrote:
select * from table where col = function() ;
(2) "function()" returns a number of values that are independent of the
query. Postgres should be able to optimize this to be: "select * from
table where col in (val1, val2, val3, ..valn)." I guess Postgres can
IIRC oid uses int4in/int4out and those should definitely be able to parse
-1040 into a 4 byte signed long without platform dependency, no ?
Tom Lane changed this recently to have OID use its own i/o routines.
- Thomas
IIRC oid uses int4in/int4out and those should definitely be able to parse
-1040 into a 4 byte signed long without platform dependency, no ?
Tom Lane changed this recently to have OID use its own i/o routines.
Reading the code, I don't understand it. Why would strtoul return an int in the
Zeugswetter Andreas SB [EMAIL PROTECTED] writes:
IIRC oid uses int4in/int4out and those should definitely be able to parse
-1040 into a 4 byte signed long without platform dependency, no ?
It has done that in past releases. I changed it to use unsigned display
for 7.1. Because of the past
Zeugswetter Andreas SB [EMAIL PROTECTED] writes:
Reading the code, I don't understand it. Why would strtoul return an
int in the first place ? The name seems to imply an unsigned long
return type.
What's your point?
unsigned long cvt;
cvt = strtoul(s, endptr, 10);
The trick
On Wed, 20 Dec 2000, Oliver Elphick wrote:
To create a quick self-signed certificate, use the CA.pl script
included in OpenSSL:
CA.pl -newcert
Or you can do it manually:
openssl req -new -text -out cert.req (you will have to enter a password)
mv privkey.pem cert.pem.pw
openssl rsa -in
Larry Rosenman [EMAIL PROTECTED] writes:
It would seem that the appropriate behavior would be to make the default
display format for CIDR be like "10.0.0.0/8". Now the text() conversion
function already produces this same format. I'd be inclined to leave
text() as-is and add a new
Acutally, a function can use an index scan *if* it is marked as cacheable:
(the "test" table has 1 field, col (type is int4), which is populated with
numbers 1 thru 5000)
testdb=# create function func_test_cache (int4) returns int4 as '
testdb'# select $1;
testdb'# ' LANGUAGE 'sql' with
* Tom Lane [EMAIL PROTECTED] [001221 09:49]:
Larry Rosenman [EMAIL PROTECTED] writes:
It would seem that the appropriate behavior would be to make the default
display format for CIDR be like "10.0.0.0/8". Now the text() conversion
function already produces this same format. I'd be
Tom,
while porting our patches for GiST from 7.0.3 to 7.1 we
got a problem with equal operator for _int4 -
src/backend/access/gist.c:540
/* did union leave decompressed version of oldud unchanged? */
FunctionCall3(giststate-equalFn,
Oleg Bartunov [EMAIL PROTECTED] writes:
this call produces core when one of the PointerGetDatum(ev0p-pred)
or PointerGetDatum(datum) is NULL
We use internal postgres function for array comparison -
giststate-equalFn is references to array_eq
array_eq is marked strict, so it's not expecting
On Thu, 21 Dec 2000, Tom Lane wrote:
Date: Thu, 21 Dec 2000 11:32:47 -0500
From: Tom Lane [EMAIL PROTECTED]
To: Oleg Bartunov [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [HACKERS] Re: equal operator for _int4 (array of int4)
Oleg Bartunov [EMAIL PROTECTED] writes:
this call
On Thu, 21 Dec 2000, Tom Lane wrote:
Value Default output text() abbrev()
'127.0.0.1/32'::inet 127.0.0.1 127.0.0.1/32127.0.0.1
'127.0.0.1/32'::cidr 127.0.0.1/32127.0.0.1/32127.0.0.1/32
'127/8'::cidr 127.0.0.0/8 127.0.0.0/8 127/8
Tom Lane writes:
Ryan Kirkpatrick [EMAIL PROTECTED] writes:
INSERT INTO OID_TBL(f1) VALUES ('-1040');
ERROR: oidin: error reading "-1040": value too large
That's coming from a possibly-misguided error check that I put into
oidin():
unsigned long cvt;
char *endptr;
I've very roughly (first time I'vetried
anything but hello worldc) hacked up inline comments.
pg_dump -I
Exports the comments generated through COMMENT ON
in an appropriate manner (line above) the item with a -- in front. More or
less a self documenting dump, or atleast an attempt at it.
Peter Eisentraut [EMAIL PROTECTED] writes:
if (sizeof(unsigned long) sizeof(Oid) cvt UINT_MAX)
Hm. Each part of that will generate "expression is always false"
warnings from certain overprotective compilers. A more serious problem
is that using UINT_MAX assumes that Oid is unsigned
Oleg Bartunov wrote:
On Thu, 21 Dec 2000, Hannu Krosing wrote:
Date: Thu, 21 Dec 2000 11:12:41 +0200
From: Hannu Krosing [EMAIL PROTECTED]
To: Oleg Bartunov [EMAIL PROTECTED]
Cc: Tom Lane [EMAIL PROTECTED], Bruce Momjian [EMAIL PROTECTED],
PostgreSQL-development [EMAIL
Matthew Kirkwood wrote:
On Wed, 20 Dec 2000, Oliver Elphick wrote:
To create a quick self-signed certificate, use the CA.pl script
included in OpenSSL:
...
Or you can do it manually:
openssl req -new -text -out cert.req (you will have to enter a password)
mv privkey.pem
Oleg Bartunov [EMAIL PROTECTED] writes:
What will happens if we ignore NULLs ?
Same thing that happens with hash:
regression=# create table foo (f1 int);
CREATE
regression=# create index fooi on foo using hash (f1);
CREATE
regression=# insert into foo values(1);
INSERT 292677 1
regression=#
Peter Mount writes:
1) ANT vs Make
I suggest we keep supporting both methods for now to see how people get on.
If you're confident about ANT is suggest that you dump the make interface
because otherwise you increase the possible failure scenarios at the
install level alone in combinatorial
Tom Lane writes:
if (sizeof(unsigned long) sizeof(Oid) cvt UINT_MAX)
Hm. Each part of that will generate "expression is always false"
warnings from certain overprotective compilers.
Any compiler that does this will certainly issue a boatload of these all
over the tree. More
Tom Lane wrote:
mlw [EMAIL PROTECTED] writes:
There are three basic types of SQL behaviors that should be able to be
performed.
(1) "function()" returns a single value. Postgres should be able to
understand how to optimize this to be: "select * from table where col =
value" where
Is there anything for encoding a PGresult struct into something I
can pass between processes? Like turning it into a platform
independant stream that I can pass between machines?
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my
Applied.
Matthew Kirkwood wrote:
On Wed, 20 Dec 2000, Oliver Elphick wrote:
To create a quick self-signed certificate, use the CA.pl script
included in OpenSSL:
...
Or you can do it manually:
openssl req -new -text -out cert.req (you will have to enter a password)
We are already in beta, so I don't think I can apply this. I will keep
it and apply in our 7.2 development tree.
[ Charset ISO-8859-1 unsupported, converting... ]
I've very roughly (first time I've tried anything but hello world c) hacked up
inline comments.
pg_dump -I
Exports the
Some SQL92 functionality is missing from the BIT and VARBIT types.
It should be possible to enter hexadecimal values as:
B'[bit...]'[{separator...'[bit...]'}...]
X'[hexdigit...]'[{separator...'[hexdigit...]'}...]
(Cannan and Otten: SQL - The Standard Handbook, p.38)
but the hexadeximal
Oliver Elphick writes:
Some SQL92 functionality is missing from the BIT and VARBIT types.
It should be possible to enter hexadecimal values as:
B'[bit...]'[{separator...'[bit...]'}...]
X'[hexdigit...]'[{separator...'[hexdigit...]'}...]
(Cannan and Otten: SQL - The Standard Handbook,
Peter Eisentraut wrote:
Oliver Elphick writes:
Some SQL92 functionality is missing from the BIT and VARBIT types.
It should be possible to enter hexadecimal values as:
...
This was omitted because in SQL99 the X'1001' notation also serves as a
binary large object value under
I said:
Other than that, it seems like it'd work, and it'd allow us to do a
normal transaction commit internally in VACUUM, which is a lot cleaner
than what VACUUM does now.
I punted on actually changing repair_frag's RecordTransactionCommit()
call into
Believe it or not, I was just about to start working on comment support (by
practicing in phpPgAdmin, so I'm happy to look over the code to see if I can
address the issues raised, and maybe to do it for all database objects...?
Chris
-Original Message-
From: [EMAIL PROTECTED]
Some SQL92 functionality is missing from the BIT and VARBIT types.
It should be possible to enter hexadecimal values as:
B'[bit...]'[{separator...'[bit...]'}...]
X'[hexdigit...]'[{separator...'[hexdigit...]'}...]
(Cannan and Otten: SQL - The Standard Handbook, p.38)
but the
"Christopher Kings-Lynne" wrote:
I have been using the BIT and VARBIT types in Postgres 7.0.3 (undocumented I
believe), and I note that the _input_ format is as follows:
update blah set flags='b101001'; -- Binary
That is still accepted.
update blah set flags='xff45'; -- Hex
That
If our application for input is written in PHP (4.0.2)
How do we notify PostgreSQL that the frontend encoding
is 'BIG5' ? (pg_exec("\encoding BIG5") failed.)
I know there are some patches for supporting \encoding in PHP. Do you
want to get them?
Sorry for the delay. Here are the
40 matches
Mail list logo
