Re: [HACKERS] Roadmap for FE/BE protocol redesign

[Justin Clift]

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, not later) to make it
more likely they can get done.  What I'm not willing to do is define
the release in terms of "it happens when these things are done".  We
learned the folly of that approach in 7.1 and 7.2.  Setting a target
date and sticking to it works *much* better.
Yep, we both seem to be saying that we'd like these features, but we 
don't want to see them become delay-points.


+ 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. 
I can't see any need for protocol-level support for such a thing.
Why wouldn't it just be some more SQL commands?
Not sure.  It seems like 2PC will be required/desirable within the year 
for better support of some clustering scenarios, so we "might as well 
look at it now".  When I was reading Satoshi's stuff a while ago I 
thought it was a protcol level thing, not a SQL command level thing, but 
don't really care either way.  :)

Regards and best wishes,

Justin Clift


(Not that I believe in 2PC as a real-world solution anyway, but that's
a different argument...)
			regards, tom lane


--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] [BUGS] Bug #908: Can not INSERT Cyrilic characters when use

[Tatsuo Ishii]

> > > 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 correct UTF-8 character sequences? For me
it seems not.
--
Tatsuo Ishii

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Roadmap for FE/BE protocol redesign

[Justin Clift]

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?

:-)

Regards and best wishes,

Justin Clift

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Roadmap for FE/BE protocol redesign

[Justin Clift]

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 such information is broken by design.  (And if that means the
JDBC spec is broken, then the JDBC spec is broken.)
Just to start with, if I do "SELECT * FROM view", am I going to see the
info associated with the view column, or with the hypothetical
underlying table column?  (Actually, didn't I already make a list of a
bunch of ways in which this concept is underspecified?  AFAIR, you
didn't suggest answers to any of those questions ... but we need answers
to all of them if we are going to implement the feature.)
The problem Dave is suggesting this as a first attempt at a solution for 
is that with ODBC, a frontend (i.e. OpenOffice) asks the ODBC driver 
which columns are NULLable, etc.  And the ODBC driver is getting the 
info wrong, then passing back the incorrect info.

So, when a person goes to insert a row into a table with a 
SERIAL/SEQUENCE based column, OpenOffice has been told the column isn't 
NULLable and forces the user to enter a value.  Voila, it doesn't work 
with sequences.  :(

It's likely possible to add to the ODBC driver some way of getting the 
info right, but Dave is also looking for a way of making this easier 
into the future for similar problems.  i.e. Let the database explicitly 
have info about what each column can do.

That's my understanding of it anyway.

:-)

Regards and best wishes,

Justin Clift


			regards, tom lane


--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org

Re: [HACKERS] Roadmap for FE/BE protocol redesign

[Bruce Momjian]

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 conditions?
> 
> If we're revising the protocol, there's no reason to hack up the column
> label to carry two pieces of info; it'd be cleaner to provide a separate
> slot in the T message to carry the table name.  I just want to see a
> reasonably complete spec for what the feature is supposed to do, before
> we buy into it ...

I don't think we can get a complete spec, and hence the _hack_ idea.  :-)

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: Beta Schedule (was Re: [HACKERS] Roadmap for FE/BE protocol redesign)

[Christopher Kings-Lynne]

> 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
> without good concrete arguments for doing so.

There really is no rush...

I'm well-versed in PostgreSQL, and even I haven't upgraded some of our
production servers to even 7.3 yet (thanks to pg_dump dependency
nightmare)..

BTW, so no-one conflicts, I'm doing up pg_get_triggerdef(oid) at the moment.
Once that's done, I'll be able to submit a redone psql \d output that
includes the trigger definition.

Cheers,

Chris


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Roadmap for FE/BE protocol redesign

[Justin Clift]

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 a
enough-features-basis.
Hmmm, I feel we should decide on features that will make an 8.0 release 
meaningful, and *somehow* work to making sure they are ready for the 
release.

With 7.1/7.2, Tom mentioned us being delayed because specific features 
we were waiting for became dependant on one person.

Would it be feasible to investigate approaches for having the Win32 and 
PITR work be shared amongst a few very-interested volunteers, so that 
people can cover for each other's downtime?  Not sure of the 
confidentiality level of the Win32/PITR patches at present, but I'd 
guess there would be at least a few solid volunteers willing to 
contribute to the Win32/PITR ports if we asked for people to step forwards.

:-)

Regards and best wishes,

Justin Clift

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Roadmap for FE/BE protocol redesign

[Tom Lane]

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 revising the protocol, there's no reason to hack up the column
label to carry two pieces of info; it'd be cleaner to provide a separate
slot in the T message to carry the table name.  I just want to see a
reasonably complete spec for what the feature is supposed to do, before
we buy into it ...

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] Roadmap for FE/BE protocol redesign

[Bruce Momjian]

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 such information is broken by design.  (And if that means the
> JDBC spec is broken, then the JDBC spec is broken.)
> 
> Just to start with, if I do "SELECT * FROM view", am I going to see the
> info associated with the view column, or with the hypothetical
> underlying table column?  (Actually, didn't I already make a list of a
> bunch of ways in which this concept is underspecified?  AFAIR, you
> didn't suggest answers to any of those questions ... but we need answers
> to all of them if we are going to implement the feature.)

I was willing to add a hack to enable default column labels to be
"table.column" --- that seemed like the least obtrusive.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] SQL99 ARRAY support proposal

[Christopher Kings-Lynne]

> 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 
> resort to anyarray1/anyelement1, etc. Does this sound correct?
> 
> Also, an implementation question: if I have a type oid for an element, 
> what is the preferred method for determining the corresponding array? 
> I'm thinking that the most efficient method might be to use the 
> element-type name with a '_' prepended to get the array-type oid, but 
> that seems ugly. Thoughts?

What about a cast?  1::arraytype

Chris


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] [INTERFACES] Roadmap for FE/BE protocol redesign

[Bruce Badger]

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 application can talk to various databases
> of
> > various vintages.
> > 
> how about a system table, say pg_features which can be queried by the fe
> interface?  This could be a table of bools with named features and/or
> other little widgets for compatibility.  No protocol modification
> required, unless the scope of the protocol change is such that you can't
> execute a connection and a query.

But wouldn't you have to connect to get this information?  Surely this
is a catch 22.



---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] [GENERAL] division by zero

[Tom Lane]

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, but chardiv as well for "char".

Good catch --- thanks!

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] [GENERAL] division by zero

[Stephan Szabo]

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:
>
> 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, but chardiv as well for "char".



---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] [INTERFACES] Roadmap for FE/BE protocol redesign

[Merlin Moncure]

> 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 vintages.
> 
how about a system table, say pg_features which can be queried by the fe
interface?  This could be a table of bools with named features and/or
other little widgets for compatibility.  No protocol modification
required, unless the scope of the protocol change is such that you can't
execute a connection and a query.

Merlin


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] [GENERAL] division by zero

[Doug Royer]

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/borland
compiler).  All these weird issues are a direct result of windows's dos
legacy.  Try it and see.


That must be a Microsoft extension - it is not standard c++.

--

 Doug Royer |   http://INET-Consulting.com
 ---|-
 [EMAIL PROTECTED] | Office: (208)612-INET
 http://Royer.com/People/Doug   |Fax: (866)594-8574
|   Cell: (208)520-4044
We Do Standards - You Need Standards


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [HACKERS] Roadmap for FE/BE protocol redesign

[Tom Lane]

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
> column, and use currval().

There was some talk awhile back of inventing INSERT ... RETURNING and
UPDATE ... RETURNING commands so that you could pass back computed
values to the frontend without an extra query.  It doesn't seem to have
gotten further than a TODO item yet, though.  AFAICS this does not need
a protocol extension, anyway --- it'd look just the same as a SELECT
at the protocol level.

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Roadmap for FE/BE protocol redesign

[Ashley Cambrell]

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 use currval().
  

Ok.  I forget about that.  Even so, it would still be nice to have a
bind like interface... :-)

Ashley Cambrell

Re: [HACKERS] Roadmap for FE/BE protocol redesign

[Neil Conway]

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 Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC




---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] [GENERAL] division by zero

[Merlin Moncure]

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).  All these weird issues are a direct result of windows's dos
legacy.  Try it and see.

Merlin

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] [INTERFACES] Roadmap for FE/BE protocol redesign

[Tom Lane]

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 will take.

It would probably be a good idea to improve that message to mention
exactly what range of protocol versions the backend does support.
However, this will do you little good for talking to existing backends
:-(

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] Roadmap for FE/BE protocol redesign

[Rod Taylor]

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.
> 
> As opposed to knowing what?  You send the version number you wish to speak;
> either the backend can handle it, or not.

At some point PostgreSQL will have enough users that changing it will
piss them off.  If the backend cannot handle whats been requested, we
may want to consider negotiating a protocol that both can handle.

Anyway, it doesn't really affect me one way or the other.  So whatever
you like is probably fine.
-- 
Rod Taylor <[EMAIL PROTECTED]>

PGP Key: http://www.rbt.ca/rbtpub.asc


signature.asc
Description: This is a digitally signed message part

Re: [HACKERS] [INTERFACES] Roadmap for FE/BE protocol redesign

[Bruce Badger]

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.
> 
> As opposed to knowing what?  You send the version number you wish to speak;
> either the backend can handle it, or not.

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 vintages.

I suppose that the client can just keep retrying the connection with
different versions until it gets a match, though.


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] [GENERAL] division by zero

[Doug Royer]

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/catch system.
No, try/catch does not trap division by zero unless the underlying
implementation throws an error there is nothing to catch.
On Unix's trap for signal SIGFPE - standard POSIX.

--

 Doug Royer |   http://INET-Consulting.com
 ---|-
 [EMAIL PROTECTED] | Office: (208)612-INET
 http://Royer.com/People/Doug   |Fax: (866)594-8574
|   Cell: (208)520-4044
We Do Standards - You Need Standards

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Roadmap for FE/BE protocol redesign

[Ashley Cambrell]

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 require
protocol changes)?
 

What about binding variables ala oracle's ociparse -> ocibindbyname -> 
ociexecute -> ocifetch ?  I know you can do most of it via SQL 
(PREPARE/EXECUTE) but you can't do 'RETURN x INTO :x' as it stands.  
This would also get around the problem of getting values from newly 
inserted rows (eg PKs) without resorting to OIDs.  Not entirely a FE/BE 
issue... but worth considering in any redesign.

Ashley Cambrell



---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] [INTERFACES] Roadmap for FE/BE protocol redesign

[Tom Lane]

"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 example, since it would have to be negotiated long
before any more general-purpose negotiation could occur.  (You do want
the connection authentication exchange to happen under cover of SSL, no?)

ISTM most of the other features you might want to turn on and off can be
handled as SET commands: the client tries to SET a variable, the backend
either accepts it or returns an error.  No need for special protocol
support if you do it that way.  Can you point to any examples that have
to have a special protocol feature instead?

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] [GENERAL] division by zero

[Tom Lane]

"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 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

if (divisor == 0)
elog(ERROR, "Integer division by zero");

before each of those trouble spots.  This would have the advantage that
the user would not see a potentially misleading reference to a floating-
point error condition, as he does now on most Unixen because of the
SIGFPE signal.

2.  Internal divisions that might accidentally divide by 0.  These cases
would all represent programmer error, IMHO, and should never happen.
So probably a core dump is okay --- it's no worse than what happens when
you dereference a pointer incorrectly.  Certainly we need not fool
around with Microsoftish C extensions to avoid these.

The only thing that's really bothering me at the moment is the fact that
on Mac OS X, the second case (internal errors) would pass undetected.
This may not be too bad because the same errors *would* get caught on
every other platform, but it's still going to be a handicap to anyone
doing code development on OS X.  It'd be like developing on a platform
that doesn't trap null-pointer dereferences :-(.  But there's little we
can do about that except pester Apple to upgrade their error trapping.

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] [INTERFACES] Roadmap for FE/BE protocol redesign

[Magnus Hagander]

> * 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 variable settings to startup packet's
> PGOPTIONS field.  Ideally we could get back to the point where a
> standard connection startup takes only one packet in each
> direction.

How about a bitmap field of "additional features" supported by
client/backend that can be negotiated? (Doesn't have to be bitmap, of
course, but the idea..) That way the server (or client - doesn't matter
who goes first, I guess) could say "I support X and Y, but not Z and Q".
If the client supports both X and Y, both are enabled. If it supports
only X, then only X is enabled.

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. I also seem to recall there was some talk about on-wire
compression support - that would also be ideal for something like this.
I'm sure there can be more...

It should be easy to make it version-independent - just make both client
and server reject any "protocol features" that are unknown.


These are features that can be enabled/disabled in a backend/client of
the same version. It cannot (at least not easily) be handled with
protocol versioning, since you can have for example 7.4 with or without
SSL.


//Magnus

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[HACKERS] Making FETCH more spec-compliant

[Tom Lane]

SQL92 defines the cursor-fetch command as

  ::=
  FETCH [ [  ] FROM ] 
INTO 

  ::=
NEXT
  | PRIOR
  | FIRST
  | LAST
  | { ABSOLUTE | RELATIVE } 

  ::=
   [ {   }... ]

(Ignore the INTO bit, which is only relevant for embedded SQL.)

AFAICT all of these are equivalent to a MOVE of some amount followed by
FETCH 1.  In particular, "FETCH RELATIVE n" means to move n rows and
return the last of these rows; it does not mean to return all n rows,
as Postgres currently misinterprets it to do.

Does anyone object to making the above-mentioned syntaxes do what the
spec says they should do?  We would also keep the following non-spec
syntaxes:

FETCH n -- retrieve next n rows
FETCH ALL   -- retrieve all remaining rows
FETCH FORWARD   -- equivalent to FETCH NEXT
FETCH FORWARD n/ALL -- FORWARD is noise here
FETCH BACKWARD  -- equivalent to FETCH PRIOR
FETCH BACKWARD n/ALL-- retrieve n or all previous rows

As before, negative n reverses the forward/backward semantics, and
zero n re-fetches the current row (like FETCH RELATIVE 0 does per-spec).

I would like to remove the following currently-allowed-but-nonstandard
syntaxes:

FETCH RELATIVE  -- n must be given, per spec
FETCH FORWARD NEXT  -- redundant
FETCH FORWARD PRIOR -- contradiction in terms
FETCH BACKWARD NEXT -- contradiction in terms
FETCH BACKWARD PRIOR-- redundant
FETCH RELATIVE ALL  -- not standard, may as well use FORWARD
FETCH RELATIVE NEXT -- ditto
FETCH RELATIVE PRIOR-- ditto

MOVE would get the same syntax changes.  It would still be defined to
reposition the cursor exactly as FETCH would do with the same
parameters, but not return any actual row data.

I am not sure what the command status string should be for MOVE with the
SQL-specified syntaxes.  For strict compatibility with our historical
behavior (return the number of rows moved over) it should always be
"MOVE 1" (successful move) or "MOVE 0" (ran off end).  But I'm not sure
that's especially useful.  Would it be better to return the final
position (row number)?  If so, should we rethink what MOVE returns for
the Postgres cases?

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] [GENERAL] division by zero

[Merlin Moncure]

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.  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/catch system.

Katie mentioned a while back using CWinApp from MFC for the windows
port.  I advised against this based on it requiring a C++ compiler and
the MFC libs.  However, if the win32 port is going that route maybe
introducing a little c++ exception handling might be the best solution
to the int/0 problem.

Barring that, it comes down to a choice of two not very pleasant
scenarios: either adopting the __try abomination or standardizing on
non-microsoft implementation of the C run time.  You can forget using
anything from MFC in this case.

The only other solution is a #ifdef win32 around places that potentially
use integers in the divisor and do some nasty hacking.  I would prefer
to use some type of signaling or 'exception' handling to that.   The end
justifies the means, I suppose.  

Merlin

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] [GENERAL] division by zero

[Tom Lane]

"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()) )
>   {
>   puts("in except");
>   } 

This is not C.

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Roadmap for FE/BE protocol redesign

[Tom Lane]

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 number you wish to speak;
either the backend can handle it, or not.

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Roadmap for FE/BE protocol redesign

[Merlin Moncure]

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.

Merlin

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Roadmap for FE/BE protocol redesign

[Rod Taylor]

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 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.

If you send version A, and the backend responds don't know A, but I know
A - 2, then libpq may want to try speaking A - 2.

> types without calling it a protocol revision.  The protocol need only
> specify "ignore any fields whose label you do not recognize".

This is probably just as good, if it's done for both sides.

-- 
Rod Taylor <[EMAIL PROTECTED]>

PGP Key: http://www.rbt.ca/rbtpub.asc


signature.asc
Description: This is a digitally signed message part

Re: [HACKERS] [GENERAL] division by zero

[Merlin Moncure]

> 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"

int HandleException( int iExcept );

int main(int argc, char* argv[])
{
int b = 0;
int a;

puts("hello");
__try
{
puts("in try");
a = 0/b;
}
__except( HandleException(GetExceptionCode()) )
{
puts("in except");
} 

puts("world");
}

int HandleException( int iExcept )
{
if (iExcept == EXCEPTION_INT_DIVIDE_BY_ZERO) 
{   
puts("Handled int/0 exception");
return EXCEPTION_EXECUTE_HANDLER;
}
/* call the system handler and crash */
return EXCEPTION_CONTINUE_SEARCH ;  
}

Merlin

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Roadmap for FE/BE protocol redesign

[Tom Lane]

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
the latest, and the backend speaks that version to you.

One thing I want to do though is relax the protocol-level constraints
on certain message contents: for example, if ErrorMessage becomes a
collection of labeled fields, it should be possible to add new field
types without calling it a protocol revision.  The protocol need only
specify "ignore any fields whose label you do not recognize".

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] 7.4 vs 8.0 WAS Roadmap for FE/BE protocol redesign

[Robert Treat]

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 
> version for a few days now.
> 
> The scenario that's appealing to me the most is this for the next release:
> 
> PostgreSQL 8.0
> **
> 
> + Includes PITR and the Win32 port
> 
> + 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.
> 
> + Other things optional of course.
> 
> 
> Personally, I'd rather we go for PostgreSQL 8.0, waiting a while extra 
> for PITR and Win32 if needed, and also properly co-ordinate all of the 
> release process information (website updates, package builds, Announce 
> to the mailing lists and news sources).
> 
I don't think PITR or Win32 (or even replication) warrant an 8.0, since
none of those should effect client/server interaction and/or backward
compatibility. (Or at least not as much as schema support did, which
required most "adminy" apps to be worked over) 

A protocol change however, would warrant a version number bump IMHO. I
would guess that by the time all of the protocol changes could be
completed, we'd have win32 or pitr, so it will hopefully be moot. 

Robert Treat 



---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] Roadmap for FE/BE protocol redesign

[Tom Lane]

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 a way where we can add stuff later, like passing
> it as a simple NULL-terminated string that can get split up on the
> client end.

Yeah, I was envisioning something with multiple labeled fields so that
more stuff can be added later without a protocol change (likewise for
StartupPacket and ErrorMessage).  But again, I don't want this thread to
get into any details about specific tasks --- let's try to get a view of
the forest before we start hewing down individual trees...


>> We've gotten away with this approach in the past, but the
>> last time was release 6.4.  I fully expect to hear more complaints now.

> I think such compatibility is sufficient.  We can mention in the
> releases notes that they should upgrade there servers before their
> clients.

I'd be really happy if we can make that stick.  There's enough work to
be done here without trying to develop a multiprotocol version of
libpq.

It would be good to hear some words from the JDBC and ODBC developers
about what sort of plans they'd have for updating those interfaces.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Roadmap for FE/BE protocol redesign

[Rod Taylor]

> * 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 To Know?)

Could it include transaction depth with the assumption nested
transactions will arrive at some point?

> * XML support?  If we do anything, I'd want some extensible solution to
> allowing multiple query-result output formats from the backend, not an
> XML-specific hack.  For one thing, that would allow the actual appearance
> of any XML support to happen later.

> One of the $64 questions that has to be answered is how much work we're
> willing to expend on backwards compatibility.  The path of least
> resistance would be to handle it the same way we've done protocol
> revisions in the past: the backend will be able to handle both old and new
> protocols (so it can talk to old clients) but libpq would be revised to
> speak only the new protocol (so new/recompiled clients couldn't talk to
> old backends).  We've gotten away with this approach in the past, but the
> last time was release 6.4.  I fully expect to hear more complaints now.

I wouldn't worry about backward compatibility complaints too much BUT
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 
incremental changes to the protocol.

-- 
Rod Taylor <[EMAIL PROTECTED]>

PGP Key: http://www.rbt.ca/rbtpub.asc


signature.asc
Description: This is a digitally signed message part

Re: [HACKERS] Roadmap for FE/BE protocol redesign

[Tom Lane]

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 later) to make it
more likely they can get done.  What I'm not willing to do is define
the release in terms of "it happens when these things are done".  We
learned the folly of that approach in 7.1 and 7.2.  Setting a target
date and sticking to it works *much* better.

> + 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. 

I can't see any need for protocol-level support for such a thing.
Why wouldn't it just be some more SQL commands?

(Not that I believe in 2PC as a real-world solution anyway, but that's
a different argument...)

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] Roadmap for FE/BE protocol redesign

[Bruce Momjian]

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 of adding
> variable settings to startup packet's PGOPTIONS field.  Ideally we could
> get back to the point where a standard connection startup takes only one
> packet in each direction.

Should we pass this in a way where we can add stuff later, like passing
it as a simple NULL-terminated string that can get split up on the
client end.

> One of the $64 questions that has to be answered is how much work we're
> willing to expend on backwards compatibility.  The path of least
> resistance would be to handle it the same way we've done protocol
> revisions in the past: the backend will be able to handle both old and new
> protocols (so it can talk to old clients) but libpq would be revised to
> speak only the new protocol (so new/recompiled clients couldn't talk to
> old backends).  We've gotten away with this approach in the past, but the
> last time was release 6.4.  I fully expect to hear more complaints now.

I think such compatibility is sufficient.  We can mention in the
releases notes that they should upgrade there servers before their
clients.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Roadmap for FE/BE protocol redesign

[Rod Taylor]

> + 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 nothing to do
with 2 phase commits -- but were used as a marker to direct replication.

We may want to consider leaving some space for a server / server style
communication (Cluster ID, etc.)

-- 
Rod Taylor <[EMAIL PROTECTED]>

PGP Key: http://www.rbt.ca/rbtpub.asc


signature.asc
Description: This is a digitally signed message part

Re: [HACKERS] Roadmap for FE/BE protocol redesign

[Justin Clift]

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 this for the next release:

PostgreSQL 8.0
**
+ Includes PITR and the Win32 port

+ 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.

+ Other things optional of course.

Personally, I'd rather we go for PostgreSQL 8.0, waiting a while extra 
for PITR and Win32 if needed, and also properly co-ordinate all of the 
release process information (website updates, package builds, Announce 
to the mailing lists and news sources).

Regards and best wishes,

Justin Clift

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org

[HACKERS] Roadmap for FE/BE protocol redesign

[Tom Lane]

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 changes)?


* Extend ERROR and NOTICE messages to carry multiple fields, including
(as appropriate) a spec-compliant error code, a textual position in the
original query string, information about the source-code location where
the error was reported, etc.

* Consider extending NOTIFY messages to allow a parameter to be carried.

* Fix COPY protocol to allow graceful error recovery (more graceful than
aborting the connection, at least) and to support COPY BINARY to/from
frontend.

* Redesign fastpath function call protocol to eliminate the problems cited
in the source code comments (src/backend/tcop/fastpath.c), and to
eliminate the security hole of accepting unchecked internal representation
from frontend.  Also consider a fastpath for execution of PREPAREd queries.

* Re-institute type-specific send/receive conversion routines to allow
some modest amount of architecture independence for binary data.  This'd
provide a place to check for bogus internal representation during fastpath
input and COPY BINARY IN, too, thus alleviating security concerns.

* Get rid of hardwired field sizes in StartupPacket --- use
variable-length null-terminated strings.  Fixes problem with usernames
being limited to 32 characters, gets around unreasonable limitation on
PGOPTIONS length.  Also can remove unused fields.

* 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
variable settings to startup packet's PGOPTIONS field.  Ideally we could
get back to the point where a standard connection startup takes only one
packet in each direction.

* 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 To Know?)

* XML support?  If we do anything, I'd want some extensible solution to
allowing multiple query-result output formats from the backend, not an
XML-specific hack.  For one thing, that would allow the actual appearance
of any XML support to happen later.


One of the $64 questions that has to be answered is how much work we're
willing to expend on backwards compatibility.  The path of least
resistance would be to handle it the same way we've done protocol
revisions in the past: the backend will be able to handle both old and new
protocols (so it can talk to old clients) but libpq would be revised to
speak only the new protocol (so new/recompiled clients couldn't talk to
old backends).  We've gotten away with this approach in the past, but the
last time was release 6.4.  I fully expect to hear more complaints now.

One way to tamp down expectations of client backwards compatibility
would be to call the release 8.0 instead of 7.4 ;-)

Comments?

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Backends created by ODBC live forever ...

[Tom Lane]

=?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 see a security issue.  There should be a TCP timeout, but it
may well be long enough (order of hours) to not be very useful to you.

> If we had something like: "max_connections_from IP" or "backend_timeout 
> TIME" we could solve the problem more easily. How about that?

max_connections_from_IP would not solve your problem: it would amount to
denying service to individual clients until whenever the TCP stack did
finally time out.

We've considered and rejected a backend-side timeout before.  I'd be
willing to consider a timeout that only runs while the backend is idle
and not inside a transaction block, but I'm not sure that solves your
problem either.  Clients that send BEGIN and then go to sleep would
defeat such a timeout.  Clients that crash mid-transaction would be a
problem too --- although I believe the kernel TCP stack will time out much
more quickly if it is trying to push unsent data than when it thinks the
connection is idle, so clients that crash while receiving data may not
be too much of a problem.

The ideal solution would really be to get your kernel to issue TCP
KEEPALIVE queries at some shorter interval than what the TCP RFCs call
for, like after a few minutes of inactivity instead of an hour or more.
I dunno whether this is adjustable in the Linux kernel, but I'd suggest
looking there first.  I don't feel very comfortable with having Postgres
second-guess the transport mechanism about whether a connection is still
alive.

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Who puts the Windows binaries on the FTP server?

[Justin Clift]

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 very straightforward.
Sounds like the "who is going to do this" needs to be sorted out. 
PeerDirect and SRA have already done this, Peter has started on it as 
well, etc.

Perhaps Peter should integrate the patches from PeerDirect or SRA, as 
he'll be most familiar with the code and it'll then take that bit of 
work off Bruce's plate?

It's just a thought anyway...  :)

Regards and best wishes,

Justin Clift


cheers

andrew


--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Backends created by ODBC live forever ...

[Tom Lane]

=?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 and exit after an hour or so, I'd expect.  It sounds
like the TCP_KEEPALIVE code on the server side is failing to detect loss
of connection.  What is the server-side platform, exactly?

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] SQL99 ARRAY support proposal

[Tom Lane]

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 these self consistent groups, we could 
> resort to anyarray1/anyelement1, etc. Does this sound correct?

Right.

> Also, an implementation question: if I have a type oid for an element, 
> what is the preferred method for determining the corresponding array? 
> I'm thinking that the most efficient method might be to use the 
> element-type name with a '_' prepended to get the array-type oid, but 
> that seems ugly. Thoughts?

I was thinking about that earlier.  Right now there is no other way.
We could consider adding a column to pg_type to link to the array type,
but I'm not sure it's worth the trouble.  I think if you look around,
there's probably already a subroutine someplace that does the lookup
using the '_foo' approach.

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] SQL99 ARRAY support proposal

[Jason M. Felice]

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 directly --- we have to fit the return-type info into an OID field.
> We could fake it by inventing one or more pseudotypes, "SAMEASPARAMn".
> 
> 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 that the return type
> is actually the common element or array type.  Then we have such
> useful behaviors as:
> 
>   array_push(anyarray, anyelement) returns anyarray
>   array_pop(anyarray) returns anyelement
>   array_subscript(anyarray, int) yields anyelement
>   singleton_array(anyelement) yields anyarray
> 
> The last three cases cannot be handled by a SAMEASPARAM construct.

... typeof($1)[], or a ARRAYELEMSAMEASPARAM construct?



I'm really liking this discussion.  I know this is sort of "out there", but
I have found in languages like StandardML and Objective CAML that templatized-
type functions are _extremely_ useful.   These languages type systems are
amazingly powerful (the language syntax is another matter *sigh*).

I'm not necessarily suggesting implementing this, but I just want to feed the
debate a bit.  I view the type system of these guys as "the ideal", and would
be in ecstacy if PostgreSQL had it, but I realize implementing the thing would
prolly be far from practical.

First, there are templatized types.  Arrays in PostgreSQL are sort of a 
kludge of templatized types, but they would be defined like so:

type a' array = 

which means that you are describing an array of some type a' (the apostrophe
indicates a type variable).

You can also create other neat templatized types as an aside:

type a' Nullable = Null | Value of a'

Which means the expressions:
Value 47 --> of type int Nullable
Null --> of type a' Nullable (determined from context)

But then, you could also say:

int array array

Or even:

int Nullable array

Which is somthing you can't in PostgreSQL but would be very nice.  But then
you could say:

let invert_matrix m : a' array array -> a' array array = 

let multiply x : a', y : a' -> a' = 

You could have more than one type variable in a templatized type or function,
true, but I've never really needed more than one.  I can imagine cases where
it would be useful, but just haven't needed one.

Plus:
* get rid of horrible 'int4_' type hacks for array.
Minus:
* can't use oid to represent exact type, rather a string of oids.
* need second table to hold function type constraints when function
  is templatized.  (or could make it params "oid array array", aka
  oid[][]!) Reserve eight or ten oids for template parameter slots
  (in other words, for a' through j' or something).

Warning: I have been called the "type nazi" 

One other thing from StandardML that I have always wanted in PostgreSQL
(or anywhere else I program, for that matter)- record types. (Warning, this is
also very wishful thinking and "out there").

In ML/CAML, a record type is defined like so:

type myrecord = {
x : int,
y : int,
s : string
};

"myrecord" is actually just type alias, the canonical record definition is:

{s:string, x:int, y:int}

... with the attributes in alphabetical order, because unless you are mucking
with pointers in C, it really doesn't matter what order they are in.  The
first advantage become very apparent:  Any two records with the same named
attributes of the same types are always of the same type.  In PostgreSQL,
this would mean that functions that operate on RECORD{x:int,y:int,s:string}
could operate on a record from any relation with those attributes.

Further, to make inheritance pretty much unnecesary, you could allow a
record with more attributes to satisfy a parameter or return value constraint.
In other words, you could call function foo(RECORD{x:int,y:int}) on a
RECORD{s:string,x:int,y:int}.

I've thought about this trick a lot.  In theory there is a possibility of
not getting what you want, but in practice it would almost never happen.  The
demostrative case would be calling distance_from_origin(RECORD{x:int,y:int})
on RECORD{x:int,y:int,z:int}, but in this case you need to make a 
distance_from_origin(RECORD{x:int,y:int,z:int}).

This way, you could make a function which operates on RECORD{oid:oid} which
could be called on any record from a table.  I've wanted to do this sort of
thing on several occasions- one application has notes which can be attached
to any row, sort of like PostgreSQL comments.  Another to keep track 

Re: [HACKERS] SQL99 ARRAY support proposal

[Joe Conway]

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 that the return type
is actually the common element or array type.  Then we have such
useful behaviors as:
array_push(anyarray, anyelement) returns anyarray
array_pop(anyarray) returns anyelement
array_subscript(anyarray, int) yields anyelement
singleton_array(anyelement) yields anyarray
The last three cases cannot be handled by a SAMEASPARAM construct.
That was my concern also. I like the above.

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 
resort to anyarray1/anyelement1, etc. Does this sound correct?

Also, an implementation question: if I have a type oid for an element, 
what is the preferred method for determining the corresponding array? 
I'm thinking that the most efficient method might be to use the 
element-type name with a '_' prepended to get the array-type oid, but 
that seems ugly. Thoughts?

Thanks,

Joe



---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] [GENERAL] division by zero

[Justin Clift]

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 SELECT
0/0 crash the process.  I have reported this to Tatsuo.
Reported the issue to the Apple guys earlier on today, but haven't heard 
anything back from them yet.

Guess we'll have to wait a few days to find out where things are at in 
regards to MacOS X.

Regards and best wishes,

Justin Clift

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] Cursors and backwards scans and SCROLL

[Bruce Momjian]

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:
> >> 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 lines of "I'm scrolling backwards
> > for you now, but there's no reason why that should work on this same query 
> > tomorrow"?
> 
> I don't see a practical way to do that --- that little bit of warning
> code would have to embed a lot of fragile assumptions about the set of
> alternatives searched by the planner.  It would probably break every
> time we improved the planner.  And the breakage would consist either of
> failing to give a warning when one is appropriate, or giving a warning
> when no other plan is really likely to be chosen; neither of which are
> going to be easily noticed or tested for.  Seems like a losing game :-(
> 
>   regards, tom lane
> 
> ---(end of broadcast)---
> TIP 6: Have you searched our list archives?
> 
> http://archives.postgresql.org
> 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

[HACKERS] Duplicate messages

[Dwayne Miller]

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 postmaster

[HACKERS] Backends created by ODBC live forever ...

[Hans-Jürgen Schönig]

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 just fine. If Access is closed properly everything is 
still fine - the server side backend dies just the way it is supposed to 
die. 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.

As you can easily imagine that there are MANY dead backends around at 
the end of the day. Is there a way for PostgreSQL to found out that the 
connection is lost? This problem occurs in combination with ODBC - I 
haven't seen it anywhere else up to now.

Did anybody encouter similar problems?

   Regards,

   Hans

---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org

Re: [HACKERS] Cursors and backwards scans and SCROLL

[Tom Lane]

"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 lines of "I'm scrolling backwards
> for you now, but there's no reason why that should work on this same query 
> tomorrow"?

I don't see a practical way to do that --- that little bit of warning
code would have to embed a lot of fragile assumptions about the set of
alternatives searched by the planner.  It would probably break every
time we improved the planner.  And the breakage would consist either of
failing to give a warning when one is appropriate, or giving a warning
when no other plan is really likely to be chosen; neither of which are
going to be easily noticed or tested for.  Seems like a losing game :-(

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [HACKERS] Cursors and backwards scans and SCROLL

[Jeroen T. Vermeulen]

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, in that whether an error occurs will depend on
> which plan the system happens to choose.  

I wouldn't worry too much about exposing implementation details at 
present--the existing situation does the same, except it pretends that
not returning data that should be there isn't an error.  Absent any
further documentation, I'd call that a bug that needs to be fixed.


> There are cases where
> identical cursor definitions might allow or not allow backwards fetch
> depending on the planner's choices.  Notice though that errors could
> occur only in cases that would silently fail in the present code; so
> existing applications that work reliably would not see such errors.

Would it be possible to give warnings in a narrow superset of the
problematic cases, something along the lines of "I'm scrolling backwards
for you now, but there's no reason why that should work on this same query 
tomorrow"?


Jeroen


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] SQL99 ARRAY support proposal

[Tom Lane]

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 fake it by inventing one or more pseudotypes, "SAMEASPARAMn".

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 that the return type
is actually the common element or array type.  Then we have such
useful behaviors as:

array_push(anyarray, anyelement) returns anyarray
array_pop(anyarray) returns anyelement
array_subscript(anyarray, int) yields anyelement
singleton_array(anyelement) yields anyarray

The last three cases cannot be handled by a SAMEASPARAM construct.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Cursors and backwards scans and SCROLL

[Tom Lane]

"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 but it will penalize only these
>> cases that absolutely need it. The penalty will of course be 
>> heavier ;(

> rescan can only work in serializable isolation, no?

I had thought about this and concluded it was not worth the trouble.
It could be made to work if we copy the snapshot data from old plan to
new, but realistically there's no value in it.  Existing applications
that are successfully using backwards-fetch are using queries that don't
need materialization; therefore there's no compatibility gain from
adding this extra code.

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Cursors and backwards scans and SCROLL

[Zeugswetter Andreas SB SD]

>> 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 plan the system happens to choose.  There are cases where
>> identical cursor definitions might allow or not allow backwards fetch
>> depending on the planner's choices. Notice though that errors could
>> occur only in cases that would silently fail in the present code; so
>> existing applications that work reliably would not see such errors.

> 2. like your #2,

I vote #2 also.

> 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 but it will penalize only these
> cases that absolutely need it. The penalty will of course be 
> heavier ;(

rescan can only work in serializable isolation, no?
In committed read isolation you will see different (just comitted) rows
from a rescan.

Andreas

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] Who puts the Windows binaries on the FTP server?

[Dave Page]

> -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 ftpsite - if not you'll have Jason 
> after you 
> > before long :-)
> 
> The source?  It's the standard version of cygwin.  It's just packaged 
> differently.  :)
> 

Doens't matter. The GPL requires that the source be made available from
the same place as the binaries. Someone got pulled up on that on on the
pgsql-cygwin list the other day after publicising a similar installer to
yours.

Regards, Dave.

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster