Open items

Here are the open items. I think once they are resolved we can head
into beta:

pg_dump multiple -t (?)
PITR backup status file
win32 binary version stamps
server logging process (?)
pg_autovacuum integration (in queue)
pg_dump fixes (in queue)

Does anyone have any more?

win32 signal safe socket handler
win32 query cancel in psql (?)

Merlin

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Bruce Momjian
Sent: 02 August 2004 20:36
To: PostgreSQL-development
Subject: [HACKERS] Open items

win32 binary version stamps

Magnus has just gone on holiday for a couple of weeks but before he left
he did tell me he'd submitted what was hopefully the final patch for
this. I haven't seen it yet though - is it stuck in the queue?

Regards, Dave.

Unless he's posted from an address that I dont' recognize, it isn't in the
queue ... at least not for approval ...

On Mon, 2 Aug 2004, Dave Page wrote:

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Bruce Momjian
Sent: 02 August 2004 20:36
To: PostgreSQL-development
Subject: [HACKERS] Open items

win32 binary version stamps

Magnus has just gone on holiday for a couple of weeks but before he left
he did tell me he'd submitted what was hopefully the final patch for
this. I haven't seen it yet though - is it stuck in the queue?

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

-----Original Message-----
From: Marc G. Fournier [mailto:scrappy@postgresql.org]
Sent: 02 August 2004 21:25
To: Dave Page
Cc: Bruce Momjian; PostgreSQL-development
Subject: Re: [HACKERS] Open items

Unless he's posted from an address that I dont' recognize, it
isn't in the queue ... at least not for approval ...

:-( OK, thanks for looking.

Regards, Dave

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Here are the open items. I think once they are resolved we can head
into beta:
...
Does anyone have any more?

contrib/dbsize doesn't even compile, and I'm still of the opinion that
oid2name is going to be pretty useless if it doesn't know about
tablespaces.

FWIW, the binary-version-stamp issue did not strike me as something
that has to be fixed before beta.

regards, tom lane

"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:

Does anyone have any more?

win32 signal safe socket handler

I thought that was solved long ago?

win32 query cancel in psql (?)

What's the issue here?

regards, tom lane

On Mon, 2004-08-02 at 12:35, Bruce Momjian wrote:

Does anyone have any more?

From reading the lists it seems like most of PITR is in. However, I

can't find any docs for it so I don't know how I'd test it. I downloaded
the latest snapshot and don't immediately see anything about PITR.

Regards,
Jeff Davis

OK, added. These items are not required for beta.

---------------------------------------------------------------------------

Merlin Moncure wrote:

Here are the open items. I think once they are resolved we can head
into beta:

pg_dump multiple -t (?)
PITR backup status file
win32 binary version stamps
server logging process (?)
pg_autovacuum integration (in queue)
pg_dump fixes (in queue)

Does anyone have any more?

win32 signal safe socket handler
win32 query cancel in psql (?)

Merlin

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

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Here are the open items. I think once they are resolved we can head
into beta:
...
Does anyone have any more?

contrib/dbsize doesn't even compile, and I'm still of the opinion that
oid2name is going to be pretty useless if it doesn't know about
tablespaces.

Added to open items.

FWIW, the binary-version-stamp issue did not strike me as something
that has to be fixed before beta.

Yea, I was unclear. They all don't need to be completed for beta.

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

Tom Lane wrote:

"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:

Does anyone have any more?

win32 signal safe socket handler

I thought that was solved long ago?

win32 query cancel in psql (?)

What's the issue here?

I thought these were both solved a long ago but I kept them on the list.

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

Jeff Davis wrote:

On Mon, 2004-08-02 at 12:35, Bruce Momjian wrote:

Does anyone have any more?

From reading the lists it seems like most of PITR is in. However, I

can't find any docs for it so I don't know how I'd test it. I downloaded
the latest snapshot and don't immediately see anything about PITR.

Yep, PITR docs is an open item.

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

Bruce Momjian wrote:

Jeff Davis wrote:

On Mon, 2004-08-02 at 12:35, Bruce Momjian wrote:

Does anyone have any more?

From reading the lists it seems like most of PITR is in. However, I

can't find any docs for it so I don't know how I'd test it. I downloaded
the latest snapshot and don't immediately see anything about PITR.

Yep, PITR docs is an open item.

And is really needed because we can not play/experiment/test it without
instructions...

Regards
Gaetano Mendola

Bruce Momjian wrote:

Tom Lane wrote:

contrib/dbsize doesn't even compile, and I'm still of the opinion that
oid2name is going to be pretty useless if it doesn't know about
tablespaces.

Added to open items.

The patch I posted is now at
http://cvs.pgadmin.org/cgi-bin/viewcvs.cgi/pgadmin-tools/support/size.c?rev=HEAD

Regards,
Andreas

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here are the open items. I think once they are resolved we can head
into beta:
...
Does anyone have any more?

Two more:

It`s not a beta-blocker, but I still need to fix the postgresql.conf.sample
file to not use all those commented-out values. Unfortunately, I have not
had time to do this. If someone could take of this, it would be most
appreciated. See Tom`s notes on some issues involved:

http://archives.postgresql.org/pgsql-patches/2004-07/msg00178.php

Another reason to make sure this makes it into 8.0 is so that the new
group of users does not see the format of the file change from 8.0 to 8.1,
but can start right away with the more intuitive format.

Second, Jan promised at OSCON to fix up server-side prepare so it actually
works even if you do not have the exact types to pass in. I presume you
will then be able to do something like this:

PREPARE mystatement AS SELECT * FROM pg_class WHERE relanem = $1

which will make driver writers very, very happy.

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200408021700

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFBD5ePvJuQZxSWSsgRAmoGAKCwXAzTPIkvco7720ngJG+QeuYdUwCfQkAp
/Jqkq/L2UlG7C7KhmsIVFZs=
=FA/T
-----END PGP SIGNATURE-----

"Greg Sabino Mullane" <greg@turnstep.com> writes:

Second, Jan promised at OSCON to fix up server-side prepare so it actually
works even if you do not have the exact types to pass in. I presume you
will then be able to do something like this:
PREPARE mystatement AS SELECT * FROM pg_class WHERE relanem = $1
which will make driver writers very, very happy.

Why would a driver writer care? He can use the Prepare protocol
message, which already can do the above --- and more to the point,
there's already a way for him to *find out* what types were resolved.
There is no way for the SQL-level PREPARE command to provide info
about how types were resolved, so I'm not in favor of hacking the
SQL command this way.

regards, tom lane

On Tuesday 03 August 2004 08:18 am, Tom Lane wrote:

"Greg Sabino Mullane" <greg@turnstep.com> writes:

Second, Jan promised at OSCON to fix up server-side prepare so it
actually works even if you do not have the exact types to pass in. I
presume you will then be able to do something like this:
PREPARE mystatement AS SELECT * FROM pg_class WHERE relanem = $1
which will make driver writers very, very happy.

Why would a driver writer care? He can use the Prepare protocol
message, which already can do the above --- and more to the point,
there's already a way for him to *find out* what types were resolved.
There is no way for the SQL-level PREPARE command to provide info
about how types were resolved, so I'm not in favor of hacking the
SQL command this way.

Quoth the manual (7.4):
Presently, prepared statements for use with PQexecPrepared must be set up
by executing an SQL PREPARE command, which is typically sent with PQexec
(though any of libpq's query-submission functions may be used). A
lower-level interface for preparing statements may be offered in a future
release.

Does the new, 8.0 libpq have an interface to the prepare protocol message?

--
Jonathan Gardner
jgardner@jonathangardner.net

First of all "promised at OSCON to fix" is a bit exaggerated. I said I
will look into the issue and see what can be done.

Having done something similar for the SPI manager once, so that
parameters can have unknown type and the code calling SPI_prepare() will
find the chosen types in the type array, so that the code calling
SPI_execp() can do the appropriate type casting, my idea is that
preparing a statement does the same and exec prepared actually accepts
unknown type arguments and calls the typein function before running the
plan. However, I still need to look at the code ...

If this is doable that way, we could log it as an open issue that needs
to be finished for release.

Jan

On 8/3/2004 1:18 PM, Jonathan Gardner wrote:

On Tuesday 03 August 2004 08:18 am, Tom Lane wrote:

"Greg Sabino Mullane" <greg@turnstep.com> writes:

Second, Jan promised at OSCON to fix up server-side prepare so it
actually works even if you do not have the exact types to pass in. I
presume you will then be able to do something like this:
PREPARE mystatement AS SELECT * FROM pg_class WHERE relanem = $1
which will make driver writers very, very happy.

Why would a driver writer care? He can use the Prepare protocol
message, which already can do the above --- and more to the point,
there's already a way for him to *find out* what types were resolved.
There is no way for the SQL-level PREPARE command to provide info
about how types were resolved, so I'm not in favor of hacking the
SQL command this way.

Quoth the manual (7.4):
Presently, prepared statements for use with PQexecPrepared must be set up
by executing an SQL PREPARE command, which is typically sent with PQexec
(though any of libpq's query-submission functions may be used). A
lower-level interface for preparing statements may be offered in a future
release.

Does the new, 8.0 libpq have an interface to the prepare protocol message?

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Jan Wieck <JanWieck@Yahoo.com> writes:

Having done something similar for the SPI manager once, so that
parameters can have unknown type and the code calling SPI_prepare() will
find the chosen types in the type array, so that the code calling
SPI_execp() can do the appropriate type casting, my idea is that
preparing a statement does the same and exec prepared actually accepts
unknown type arguments and calls the typein function before running the
plan. However, I still need to look at the code ...

This is already *done*. All we need is to devise a reasonable API for
libpq to provide access to the V3-protocol Prepare message. I suspect
that we'd want it to bundle a Prepare and a Describe Statement
operation, so that the user would get back the list of actual argument
types in the same call that issues the prepare. But I haven't thought
it through in detail.

If this is doable that way, we could log it as an open issue that needs
to be finished for release.

[ shrug ] Arguably it was something that should have been done for 7.4.
If someone wants to step up to the plate now, I won't stand in the way.

regards, tom lane

On Tuesday 03 August 2004 11:46 am, Tom Lane wrote:

Jan Wieck <JanWieck@Yahoo.com> writes:

Having done something similar for the SPI manager once, so that
parameters can have unknown type and the code calling SPI_prepare()
will find the chosen types in the type array, so that the code calling
SPI_execp() can do the appropriate type casting, my idea is that
preparing a statement does the same and exec prepared actually accepts
unknown type arguments and calls the typein function before running the
plan. However, I still need to look at the code ...

This is already *done*. All we need is to devise a reasonable API for
libpq to provide access to the V3-protocol Prepare message. I suspect
that we'd want it to bundle a Prepare and a Describe Statement
operation, so that the user would get back the list of actual argument
types in the same call that issues the prepare. But I haven't thought
it through in detail.

If this is doable that way, we could log it as an open issue that needs
to be finished for release.

[ shrug ] Arguably it was something that should have been done for 7.4.
If someone wants to step up to the plate now, I won't stand in the way.

As far as API, how about this: (My C is rusty...)

typedef struct PGpreparedStmt {
char *name,
char *stmt,
int nParams,
Oid *paramTypes,
} PGpreparedStmt;

PGpreparedStmt *PQprepare(PGconn *, char *name, char *stmt);

We could make the PGpreparedStmt struct opaque to the client (like PGresult
and PGconn) and provide accessor functions.

const char *PQpreparedStmtName(const PGpreparedStmt *);
const char *PQpreparedStmtStmt(const PGpreparedStmt *);
int PQpreparedStmtNParams(const PGpreparedStmt *);
const Oid *PQpreparedStmtParamTypes(const PGpreparedStmt *);

Question: Can we handle asynchronous prepares? (I think we could follow the
notifies method - it just magically picks it up while you consumeInput.)

int PQsendPrepare(PGconn *, char *name, char *stmt);
PGpreparedStmt *PQgetPrepare(PGconn *);

The naming could be better. I can't think of any good alternatives right
now.

I'll look into how to actually implement this at home tonight.

--
Jonathan Gardner
jgardner@jonathangardner.net