> > 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 th
"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
> Some SQL92 functionality is missing from the BIT and VARBIT types.
>
> It should be possible to enter hexadecimal values as:
>
> B'[...]'[{...'[ X'[...]'[{...'[
> (Cannan and Otten: SQL - The Standard Handbook, p.38)
>
> but the hexadeximal form is not accepted.
I have been using the BIT a
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]
> [mail
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 CommitTransactionCommand()/StartTrans
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
Oliver Elphick writes:
> Some SQL92 functionality is missing from the BIT and VARBIT types.
>
> It should be possible to enter hexadecimal values as:
>
> B'[...]'[{...'[ X'[...]'[{...'[
> (Cannan and Otten: SQL - The Standard Handbook, p.38)
>
> but the hexadeximal form is not accepted.
This
Some SQL92 functionality is missing from the BIT and VARBIT types.
It should be possible to enter hexadecimal values as:
B'[...]'[{...'[...]'[{...'[http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839
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
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
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
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 =
> >
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.
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
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=#
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.p
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-develop
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 un
I've very roughly (first time I've tried
anything but hello world c) 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 i
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
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 1
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:
> > t
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 ex
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,
PointerGet
* 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.
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 (iscachab
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
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
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
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 pas
> > 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 i
> 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
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 Pos
* 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-
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
> > 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
> 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
> 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 isD
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 pac
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
40 matches
Mail list logo
