Bruce Momjian wrote:
Michael Paesold wrote:
Magnus Hagander wrote:
[snip]
Michael, I am not sure why you come to the conclusion that open_sync
requires turning off the disk write cache. I saw nothing to indicate
that in the thread:
I was just seeing his error message below...
http://archives.postg
Shachar Shemesh wrote:
Dave Cramer wrote:
Shachar,
I think with type oid 705 (unknown) it's safe to treat it as text.
Certainly better than punting.
Question is what DBTYPE to report it as. Options are DBTYPE_WSTR
(UTF-16 string, which means the input string must be a valid UTF-8
string), DBTYP
Hi,
i want to add support for oracle exception's like
no_data in plpgsql, can anybody guide me on this.
Regards,
Asif Ali.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---
Dave Cramer wrote:
Shachar,
I think with type oid 705 (unknown) it's safe to treat it as text.
Certainly better than punting.
Question is what DBTYPE to report it as. Options are DBTYPE_WSTR (UTF-16
string, which means the input string must be a valid UTF-8 string),
DBTYPE_STR (just dump it as I
On Wed, 16 Mar 2005, Bruce Momjian wrote:
Magnus Hagander wrote:
I'd like to see this one also considered for 8.0.x, though I'd certainly
like to see some more testing as well. Perhaps it's suitable for the
"8.0.x with extended testing" that is planned for the ARC replacement
code?
It does make a h
Neil Conway <[EMAIL PROTECTED]> writes:
> BTW, it's quite annoying that the planner scribbles on its input.
Yeah ... it would be good to fix that ...
regards, tom lane
---(end of broadcast)---
TIP 3: if posting/reading throu
Neil Conway wrote:
Do we want to share plans between call sites?
After thinking about this a little more, I think the answer is "no" --
it doesn't really buy us much, and introduces some extra complications
(e.g. resource management).
BTW, it's quite annoying that the planner scribbles on its in
Tom Lane wrote:
> Bruce Momjian writes:
> > Notice we never default to open_sync. However, on Win32, Magnus got a
> > 60% speedup by using open_sync, implemented using
> > FILE_FLAG_WRITE_THROUGH. Now, because this the fastest on Win32, I
> > think we should default to open_sync on Win32. The a
Michael Paesold wrote:
> Magnus Hagander wrote:
>
>
> >> Magnus Hagander wrote:
> >>> > Magnus prepared a trivial patch which added the O_SYNC flag
> >>> > for windows and mapped it to FILE_FLAG_WRITE_THROUGH in
> >>> > win32_open.c.
> [snip]
>
> > Michael Paesold wrote:
> >>The original patch d
Bruce Momjian writes:
> Notice we never default to open_sync. However, on Win32, Magnus got a
> 60% speedup by using open_sync, implemented using
> FILE_FLAG_WRITE_THROUGH. Now, because this the fastest on Win32, I
> think we should default to open_sync on Win32. The attached patch
> implements
Magnus Hagander wrote:
> I'd like to see this one also considered for 8.0.x, though I'd certainly
> like to see some more testing as well. Perhaps it's suitable for the
> "8.0.x with extended testing" that is planned for the ARC replacement
> code?
>
> It does make a huge difference on win32. Whil
Tom Lane wrote:
(B>>I saw Oracle's reference manual, and found ALTER DATABASE OPEN READ ONLY
(B>>command
(B>>to make a stand-by database.
(B>
(B> Perhaps, but that's *not* what the TODO item is about.
(B
(BI see.
(B
(BThanks for comments.
(B--
(BNAGAYASU Satoshi <[EMAIL PROTECTED]>
(
Satoshi Nagayasu <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Uh, no, because changing that would by definition not be a read-only
>> operation. Therefore there'd be no way to enter the read-only state,
>> and definitely no way to get out of it again.
> I saw Oracle's reference manual, and fo
Andrew Dunstan wrote:
Mark Kirkwood wrote:
Andrew Dunstan wrote:
It fixes the build error on Windows - haven't tried because i don't have
time, but I know it won't work on Cygwin, because WIN32 isn't (usually)
defined on Cygwin - see previous almost endless discussions.
Yes - I recall that discus
Mark Kirkwood wrote:
> Andrew Dunstan wrote:
>
>> It fixes the build error on Windows - haven't tried because i don't have
>> time, but I know it won't work on Cygwin, because WIN32 isn't (usually)
>> defined on Cygwin - see previous almost endless discussions.
>>
>
> Yes - I recall that discuss
Andrew Dunstan wrote:
It fixes the build error on Windows - haven't tried because i don't have
time, but I know it won't work on Cygwin, because WIN32 isn't (usually)
defined on Cygwin - see previous almost endless discussions.
Yes - I recall that discussion a while ago.
This patch should sort the
Tom Lane wrote:
(B> Uh, no, because changing that would by definition not be a read-only
(B> operation. Therefore there'd be no way to enter the read-only state,
(B> and definitely no way to get out of it again.
(B
(BI saw Oracle's reference manual, and found ALTER DATABASE OPEN READ ONLY com
Bruce Momjian wrote:
Yes, 8.1 will require a dump/reload for upgrade. I think we decided
that was going to be necessary.
That has aleady happened for 8.1:
date: 2005/02/28 03:45:21; author: neilc; state: Exp; lines: +2 -2
Implement max() and min() aggregates for array types. Pat
Mark Woodward wrote:
> > Tom Lane wrote:
> >> You can't just randomly rearrange the pg_enc enum without forcing an
> >> initdb, because the numeric values of the encodings appear in system
> >> catalogs (eg pg_conversion).
> >
> > Oh, those numbers appear in the catalogs? I didn't relealize that.
> Tom Lane wrote:
>> You can't just randomly rearrange the pg_enc enum without forcing an
>> initdb, because the numeric values of the encodings appear in system
>> catalogs (eg pg_conversion).
>
> Oh, those numbers appear in the catalogs? I didn't relealize that.
>
> I will force an initdb.
>
Doe
Tom Lane wrote:
> You can't just randomly rearrange the pg_enc enum without forcing an
> initdb, because the numeric values of the encodings appear in system
> catalogs (eg pg_conversion).
Oh, those numbers appear in the catalogs? I didn't relealize that.
I will force an initdb.
--
Bruce Mom
You can't just randomly rearrange the pg_enc enum without forcing an
initdb, because the numeric values of the encodings appear in system
catalogs (eg pg_conversion).
regards, tom lane
---(end of broadcast)---
TIP 2: you can
Nicolai Tufar wrote:
> On Wed, 16 Mar 2005 01:00:21 -0500 (EST), Bruce Momjian
> wrote:
> >
> > I have applied a modified version of your patch, attached.
>
> I am so sorry, I sent untested patch again. Thank you very
> much for patience in fixing it. The patch looks perfectly
> fine and works
On Wed, Mar 16, 2005 at 07:35:57PM +0100, Thomas Hallgren wrote:
> I have some test code that utilize SPI and does the following:
>
> 1. SPI_connect
> 2. set a savepoint (using BeginInternalSubTransaction)
> 3. execute a statement that contains a syntax error (within PG_TRY/PG_CATCH)
> 4. rollback
I have some test code that utilize SPI and does the following:
1. SPI_connect
2. set a savepoint (using BeginInternalSubTransaction)
3. execute a statement that contains a syntax error (within PG_TRY/PG_CATCH)
4. rollback to the savepoint (RollbackAndReleaseCurrentSubTransaction)
5. execute some ot
It fixes the build error on Windows - haven't tried because i don't have
time, but I know it won't work on Cygwin, because WIN32 isn't (usually)
defined on Cygwin - see previous almost endless discussions.
cheers
andrew
Mark Kirkwood wrote:
> Andrew Dunstan wrote:
>
>> ... is apparently broken
Ok then, if it's per spec, nothing to say.
Thanks to everybody, Richard and Tom, for your time.
PS : well yes, i think it is reasonably weird. I sure don't want to try
and imagine the case you're proposing. Brain's too precious to burn. I'm
confident in you to be assured it's weirder and weirdest
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> >> Even binary data? ie. You could upload a binary string straight
into
> >> PQexecParams with no octal conversion?
>
> > Well, what it means you do not have to escape data at the protocol
level
> > you don't have to be concerned about formatting t
Hello,
How do you encrypt() & decrypt() data of types INT4 or DATE?
The PGCrypto methods encrypt() and decrypt() each take BYTEA as input:
i.e.,
encrypt( data::bytea, key::bytea, type::text)
decrypt( data::bytea, key::bytea, type::text)
So how do you convert INT4 and DATE data into BYTE
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> Even binary data? ie. You could upload a binary string straight into
>> PQexecParams with no octal conversion?
> Well, what it means you do not have to escape data at the protocol level
> you don't have to be concerned about formatting the query str
Satoshi Nagayasu <[EMAIL PROTECTED]> writes:
>> * Allow a warm standby system to also allow read-only queries
> Does anyone have any plan to work on this?
> I think we need to extend the pg_database catalog to
> have a database state (read-only or writable),
> and also need to extend ALTER DATABA
David Pradier <[EMAIL PROTECTED]> writes:
> One can access the columns of the main query from the subquery,
> therefore in my own query the column "id_compte" is found,
> therefore there is no error message.
> Doesn't this count as a bug ?
No; it's required behavior per the SQL specification. Th
Nicolai Tufar wrote:
> On Wed, 16 Mar 2005 01:00:21 -0500 (EST), Bruce Momjian
> wrote:
> >
> > I have applied a modified version of your patch, attached.
>
Here is a patch that fixes the %*$ case.
FYI, I am going to pgindent snprintf.c to make it consistent so please
us CVS for your next patc
> >>Will PQexecParams automatically escape bytea data as it goes in, or
must
> >>one run it through PQescapeBytea first?
> >
> > Neither. The data does not need escaping (assuming you pass it as a
> > parameter, of course.)
>
> Even binary data? ie. You could upload a binary string straight into
David Pradier wrote:
Ok, understood.
One can access the columns of the main query from the subquery,
therefore in my own query the column "id_compte" is found,
therefore there is no error message.
Doesn't this count as a bug ?
Tricky, you could have something like:
SELECT a.* FROM a WHERE (a1,a2)
Ok, understood.
One can access the columns of the main query from the subquery,
therefore in my own query the column "id_compte" is found,
therefore there is no error message.
Doesn't this count as a bug ?
On Wed, Mar 16, 2005 at 02:24:48PM +, Richard Huxton wrote:
> David Pradier wrote:
> >A
>>>Uh, but that's what the BSD license allows --- relicensing as any other
>>>license, including commercial.
>>
>> The point remains that Chris, by himself, does not hold the copyright on
>> the PG docs and therefore cannot assign it to anyone.
>>
>> ISTM the PHP guys are essentially saying that th
David Pradier wrote:
Actually, the column "id_compte" is the primary key of the table "compte".
The column "id_compte" doesn't exist in the table "operation".
But i still don't understand why there is no error message, could you
explain a little more ?
I think it's intended for use in the WHERE cla
I've tried with 7.4.3 - *good* results with both SQL and PL/PGSQL
(actually even less that best 8.0.1: 12Mb)
I think this makes it a bug...
--strk;
On Wed, Mar 16, 2005 at 01:58:44PM +0100, [EMAIL PROTECTED] wrote:
> I've tested with 8.0.1 and get same results.
>
> --strk;
>
> On Wed, Mar 16,
I've tested with 8.0.1 and get same results.
--strk;
On Wed, Mar 16, 2005 at 01:04:03PM +0100, [EMAIL PROTECTED] wrote:
> On postgresql-8.0.0 I've faced a *really* weird behavior.
>
> A simple query (single table - simple function call - no index),
> makes postgres process grow about as much as
Hi all,
(B
(BI've read TODO list in the 8.0.1,
(Bthen I'm interested in the following topic.
(B
(B> * Allow a warm standby system to also allow read-only queries
(B
(BDoes anyone have any plan to work on this?
(B
(BI think we need to extend the pg_database catalog to
(Bhave a database sta
Actually, the column "id_compte" is the primary key of the table "compte".
The column "id_compte" doesn't exist in the table "operation".
But i still don't understand why there is no error message, could you
explain a little more ?
David
On Wed, Mar 16, 2005 at 11:49:28AM +, Richard Huxton w
Ühel kenal päeval (esmaspäev, 14. märts 2005, 22:13-0500), kirjutas
Bruce Momjian:
> Christopher Kings-Lynne wrote:
> > > I really don't intend to do that, and it does seem to happen a lot. I am
> > > the first to admit I lack tact, but often times I view the decisions made
> > > as rather arbitrar
David Pradier wrote:
But when i put this query inside another query, i don't have anymore the
error message :
select distinct id_operation from compte where id_compte in
(select id_compte from operation where not compta_g5);
No error message.
It looks like it's binding to the outer query - where yo
On Wed, 16 Mar 2005 01:00:21 -0500 (EST), Bruce Momjian
wrote:
>
> I have applied a modified version of your patch, attached.
I am so sorry, I sent untested patch again. Thank you very
much for patience in fixing it. The patch looks perfectly
fine and works under Solaris.
Under win32 I am sti
Hi everybody,
I've just run into a seemingly strange behaviour of postgresql and I'd like to
know if it's normal or what.
I've got a table "operation" in which there _isn't_ any column
"id_compte".
So when i do :
"select id_compte from operation where not compta_g5;"
I have :
"ERROR: column "id_
Andrew Dunstan wrote:
... is apparently broken for Windows and Cygwin. See for example
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=loris&dt=2005-03-16%2001:55:33
Andrew,
The attached patch seems to sort it for me, can you give it try on win32
and cygwin?
cheers
Mark
--- pg_buffercache_pages
47 matches
Mail list logo
