Tom Lane wrote:
Justin Clift <[EMAIL PROTECTED]> writes:
The scenario that's appealing to me the most is this for the next release:
PostgreSQL 8.0
+ Includes PITR and the Win32 port
If the folks doing those things can get done in time, great. I'm even
willing to push out the release schedule (now
> > > Sample Code
> > > insert into t2 (names) values ('xxx');
> >
> > What did you insert as xxx? I would like to see them as hex or octal
> > value.
> > --
> > Tatsuo Ishii
> >
> As 'xxx' I insert Cyrillic characters. Here are some hex values: E0, FE,
> DE, EE.
Are you sure that these are corr
Hi guys,
As a thought, has anyone considered if it's worth doing data compression
of the "new proposed" protocol for PostgreSQL 8.0/7.4? It was suggested
a long time ago by Joshua Drake (and his version was well accepted by
his customers from what I heard), so might this be worth adding too?
Tom Lane wrote:
"Dave Page" <[EMAIL PROTECTED]> writes:
What about the addition of pg_attribute.attrelid &
pg_attribute.attname/attnum in RowDesription messages to identify the
underlying attribute (where appropriate)?
Well, we can talk about it, but I still think that any frontend that
relies on
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I was willing to add a hack to enable default column labels to be
> > "table.column" --- that seemed like the least obtrusive.
>
> Most of the definitional issues still apply: which table name are you
> going to insert, and under what
> I had been leaning to May 1 beta, but am happy to switch to June 1 if
> you feel that makes an improvement in the odds of completing the Windows
> port. (I think it will also improve the odds of finishing this protocol
> stuff I've taken on...) I don't want to see it pushed further than that
>
Bruce Momjian wrote:
So, what should we do? Should we go another month or two and just wait
until we have enough must-have features? While not waiting on specific
features, it _is_ waiting for something to warrant a release. I guess
the big question is whether we release on a scheduled-basis or
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I was willing to add a hack to enable default column labels to be
> "table.column" --- that seemed like the least obtrusive.
Most of the definitional issues still apply: which table name are you
going to insert, and under what conditions?
If we're revis
Tom Lane wrote:
> "Dave Page" <[EMAIL PROTECTED]> writes:
> > What about the addition of pg_attribute.attrelid &
> > pg_attribute.attname/attnum in RowDesription messages to identify the
> > underlying attribute (where appropriate)?
>
> Well, we can talk about it, but I still think that any fronte
> So if I understand correctly, all instances of anyarray and anyelement
> in a function definition would need to be self-consistent, but the group
> could represent essentially any datatype with its corresponding array
> type. If we need more than one of these self consistent groups, we could
On Tue, 2003-03-11 at 09:18, Merlin Moncure wrote:
> > If the backend can not handle the version I request, but can handle a
> > prior version, I'd like to know. I am planning on having handlers for
> > multiple protocol versions in the same memory space (I'm using
> > Smalltalk, BTW) so that one
Stephan Szabo <[EMAIL PROTECTED]> writes:
>> 1. There are only about half a dozen places for a user-triggered
>> division by zero to occur (the div and mod functions for int2, int4,
>> int8; have I missed anything?). It would not be very painful to insert
> It's unlikely to come up in practice,
On Mon, 10 Mar 2003, Tom Lane wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > The only other solution is a #ifdef win32 around places that potentially
> > use integers in the divisor and do some nasty hacking.
>
> Well, it seems to me that we have two different issues to worry about:
>
>
> If the backend can not handle the version I request, but can handle a
> prior version, I'd like to know. I am planning on having handlers for
> multiple protocol versions in the same memory space (I'm using
> Smalltalk, BTW) so that one application can talk to various databases
of
> various vint
Merlin Moncure wrote:
Doug Royer wrote:
No, try/catch does not trap division by zero unless the underlying
implementation throws an error there is nothing to catch.
I am absolutely 100% sure that you can catch int/0 with a try catch
handler (in c++) on windows platforms (when compiled with ms/bo
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2003-03-10 at 16:37, Ashley Cambrell wrote:
>> This would also get around the problem of getting values from newly
>> inserted rows (eg PKs) without resorting to OIDs.
> That's not a problem: ensure that the newly inserted row has a SERIAL
> colum
Neil Conway wrote:
On Mon, 2003-03-10 at 16:37, Ashley Cambrell wrote:
This would also get around the problem of getting values from newly
inserted rows (eg PKs) without resorting to OIDs.
That's not a problem: ensure that the newly inserted row has a SERIAL
column, and
On Mon, 2003-03-10 at 16:37, Ashley Cambrell wrote:
> This would also get around the problem of getting values from newly
> inserted rows (eg PKs) without resorting to OIDs.
That's not a problem: ensure that the newly inserted row has a SERIAL
column, and use currval().
Cheers,
Neil
--
Neil C
Doug Royer wrote:
> No, try/catch does not trap division by zero unless the underlying
> implementation throws an error there is nothing to catch.
>
I am absolutely 100% sure that you can catch int/0 with a try catch
handler (in c++) on windows platforms (when compiled with ms/borland
compiler).
Bruce Badger <[EMAIL PROTECTED]> writes:
> I suppose that the client can just keep retrying the connection with
> different versions until it gets a match, though.
Right now, the backend just barfs with
FATAL: unsupported frontend protocol
so you have to do a blind search to see what it wi
On Mon, 2003-03-10 at 14:52, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> >> We already have that: you send a startup packet with a version less than
> >> the latest, and the backend speaks that version to you.
>
> > Yes, but that requires you know the backend is less than the latest
On Tue, 2003-03-11 at 06:52, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> >> We already have that: you send a startup packet with a version less than
> >> the latest, and the backend speaks that version to you.
>
> > Yes, but that requires you know the backend is less than the latest
Merlin Moncure wrote:
__try and __except, as far as I can tell are the only way to gracefully
handle certain events. There is also a __finally. This is very much a
Microsoft hack to C and not C++.
GetExceptionCode() is from the win32 api.
In C++, you get to use the much more standard try/cat
Tom Lane wrote:
This is an attempt to lay out a road map for updating the frontend/backend
protocol in 7.4. I don't at this point want to get into details on any
one of the TODO items, just get consensus that this is the set of tasks
to be tackled. Are there any areas that I've missed (that requ
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> X and Y? Well, the first thing that comes to mind is SSL support. I'm
> not sure if it's still that way, but at least it used to be a pretty
> ugly kludge there with the connection being dropped and re-connected in
> some cases.
SSL support is a bad
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> The only other solution is a #ifdef win32 around places that potentially
> use integers in the divisor and do some nasty hacking.
Well, it seems to me that we have two different issues to worry about:
1. There are only about half a dozen places for
> * Backend should pass its version number, database encoding,
> default client encoding, and possibly other data (any ideas?) to
> frontend during startup, to avoid need for explicit queries to get
> this info. We could also consider eliminating SET commands sent by
> libpq in favor of adding va
SQL92 defines the cursor-fetch command as
::=
FETCH [ [ ] FROM ]
INTO
::=
NEXT
| PRIOR
| FIRST
| LAST
| { ABSOLUTE | RELATIVE }
::=
[ { }..
Tom Lane wrote:
> This is not C.
I can't argue that; but it will compile on a C compiler on the Microsoft
platform. I'm not sure if you were answering tongue-in-cheek, so for
the benefit of the group:
__try and __except, as far as I can tell are the only way to gracefully
handle certain events.
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> After fighting with the docs a little bit, here is how to handle an
> int/0 in a C application.
> __try
> {
> puts("in try");
> a = 0/b;
> }
> __except( HandleException(GetExceptionCode()) )
>
Rod Taylor <[EMAIL PROTECTED]> writes:
>> We already have that: you send a startup packet with a version less than
>> the latest, and the backend speaks that version to you.
> Yes, but that requires you know the backend is less than the latest.
As opposed to knowing what? You send the version nu
Justin Clift wrote:
>
> PostgreSQL 8.0
> **
>
> + Includes PITR and the Win32 port
*snip*
I feel like the upcoming 7.4 is the most important release since the
introduction of toast, maybe even since the introduction of the sql
language. I wholeheartedly agree with your proposition.
On Mon, 2003-03-10 at 14:30, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > I'd be tempted to make a startup packet that will allow libpq to revert
> > back to old protocols easily enough for the future so that we can do=20
> > incremental changes to the protocol.
>
> We already have
> The big question is how to fix this on Win32. Is a test in the
integer
> division routines enough? Is there a signal to catch on Win32?
After fighting with the docs a little bit, here is how to handle an
int/0 in a C application.
#include "stdio.h"
#include "excpt.h"
#include "windows.h"
i
Rod Taylor <[EMAIL PROTECTED]> writes:
> I'd be tempted to make a startup packet that will allow libpq to revert
> back to old protocols easily enough for the future so that we can do=20
> incremental changes to the protocol.
We already have that: you send a startup packet with a version less than
On Mon, 2003-03-10 at 14:05, Justin Clift wrote:
> Tom Lane wrote:
>
> > One way to tamp down expectations of client backwards compatibility
> > would be to call the release 8.0 instead of 7.4 ;-)
> >
> > Comments?
>
> Actually, I've been thinking about the numbering of the next PostgreSQL
> v
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> * Backend should pass its version number, database encoding, default
>> client encoding, and possibly other data (any ideas?) to frontend during
>> startup, to avoid need for explicit queries to get this info.
> Should we pass this in
> * Backend's ReadyForQuery message (Z message) should carry an indication
> of current transaction status (idle/in transaction/in aborted transaction)
> so that frontend need not guess at state. Perhaps also indicate
> autocommit status. (Is there anything else that frontends would Really
> Like
Justin Clift <[EMAIL PROTECTED]> writes:
> The scenario that's appealing to me the most is this for the next release:
> PostgreSQL 8.0
> + Includes PITR and the Win32 port
If the folks doing those things can get done in time, great. I'm even
willing to push out the release schedule (now, not late
Tom Lane wrote:
> * Backend should pass its version number, database encoding, default
> client encoding, and possibly other data (any ideas?) to frontend during
> startup, to avoid need for explicit queries to get this info. We could
> also consider eliminating SET commands sent by libpq in favor
> + Not sure where Satoshi is up to with his 2 phase commit proposal, but
> that might make sense to incorporate into a wire protocol revision.
> From memory he received funding to work on it, so it might be coming
> along nicely.
One should note that his protocol changes had absolutely nothin
Tom Lane wrote:
One way to tamp down expectations of client backwards compatibility
would be to call the release 8.0 instead of 7.4 ;-)
Comments?
Actually, I've been thinking about the numbering of the next PostgreSQL
version for a few days now.
The scenario that's appealing to me the most is th
This is an attempt to lay out a road map for updating the frontend/backend
protocol in 7.4. I don't at this point want to get into details on any
one of the TODO items, just get consensus that this is the set of tasks
to be tackled. Are there any areas that I've missed (that require
protocol chan
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> As far as I have seen it did not time out - at least it seems that it
> doesn't. Also, if we were running a system with many unreliable clients
> we'd run out of memory soon. It is also a potential security problem.
I do not
Andrew Dunstan wrote:
- Original Message -
From: "Dave Page" <[EMAIL PROTECTED]>
I thought the idea was initdb would be rewritten in C. We cannot include
grep/sed etc as they're GPL...
I'd be happy to do this if it hasn't been done. After a quick perusal of the
script I think it would be ve
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> ... However, if Access crashes or if the dial-up connections goes down
> the connection is not closed explicitly and the server side backend
> stays alive forever - even if the Windows client is rebooted.
It should time out a
Joe Conway <[EMAIL PROTECTED]> writes:
> So if I understand correctly, all instances of anyarray and anyelement
> in a function definition would need to be self-consistent, but the group
> could represent essentially any datatype with its corresponding array
> type. If we need more than one of t
On Mon, Mar 10, 2003 at 09:49:47AM -0500, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Joe Conway kirjutas E, 10.03.2003 kell 05:35:
> >> CREATE OR REPLACE FUNCTION array_push (anyarray, anyscalar)
> >> RETURNS anyarray
>
> > could you make it
> > RETURNS typeof($1)
>
> Not dir
Tom Lane wrote:
But I think I like better the notion of extending my bound-together-
ANYARRAY-and-ANYELEMENT proposal,
http://archives.postgresql.org/pgsql-hackers/2003-03/msg00319.php
Suppose that we do that, and then further say that ANYARRAY or
ANYELEMENT appearing as the return type implies tha
Bruce Momjian wrote:
FWIW, this also is a problem with some of the windows ports. For
example, 'select 0/0' is unpredictable and can cause the server to gpf
and restart. This does not include the SRA port, because I don't have
it.
I just tested the SRA Win32 threaded port and both SELECT 1/0 and
Just a reminder that we could use cursors that exist after transaction
commit (WITH HOLD) and updatable cursors (WHERE CURRENT OF cursorname). :-)
---
Tom Lane wrote:
> "Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> >>
I'm receiving duplicates of all posts from pg mailer. None of the other
lists I have seem to be affected. Any way I can check if my email is
duplicated in the subscription list?
Dwayne
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmast
We have an application which syncs Access databases with PostgreSQL (I
know that this is VERY ugly). It is a simple script based Access
application. People wanted that application because they are familiar
with Microsoft stuff. When Access establishes a connection to PostgreSQL
everything is ju
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
>> There are cases where
>> identical cursor definitions might allow or not allow backwards fetch
>> depending on the planner's choices.
> Would it be possible to give warnings in a narrow superset of the
> problematic cases, something along the li
On Sun, Mar 09, 2003 at 03:35:11PM -0500, Tom Lane wrote:
>
> 2. Error out only if a backwards fetch is actually attempted on a plan
> tree that can't handle it (which could only happen if SCROLL wasn't
> given). This is efficient and flexible, but it exposes implementation
> details to the user,
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Joe Conway kirjutas E, 10.03.2003 kell 05:35:
>> CREATE OR REPLACE FUNCTION array_push (anyarray, anyscalar)
>> RETURNS anyarray
> could you make it
> RETURNS typeof($1)
Not directly --- we have to fit the return-type info into an OID field.
We could fa
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
>> but just give a warning and then run the underlying
>> query _again_, this toime with materialize on top and also do a Move to
>> reposition the cursor. This will probably not work correctly for all
>> tranasaction isolation levels though b
>> 2. Error out only if a backwards fetch is actually attempted on a plan
>> tree that can't handle it (which could only happen if SCROLL wasn't
>> given). This is efficient and flexible, but it exposes implementation
>> details to the user, in that whether an error occurs will depend on
>> which
> -Original Message-
> From: Justin Clift [mailto:[EMAIL PROTECTED]
> Sent: 09 March 2003 09:57
> To: Dave Page
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Who puts the Windows binaries on the
> FTP server?
>
>
> > PS. Is the source on the
59 matches
Mail list logo
