Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
... So the application already knows
that foo is the table and a is the column. So if the application
wants to know about details on the column a, it can execute
SELECT whatever FROM pg_attribute, pg_class WHERE relname = 'foo'
On Monday 10 March 2003 10:51 am, Tom Lane wrote:
* 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
On 16 Mar 2003, Hannu Krosing wrote:
Tom Lane kirjutas R, 14.03.2003 kell 19:15:
Greg Stark [EMAIL PROTECTED] writes:
So, just to throw out a wild idea: If you're talking about making large
changes to the on-the-wire protocol. Have you considered using an existing
database protocol?
Peter Eisentraut wrote:
I don't get it. Say I execute SELECT a, b, c FROM foo;. In order to
update that query, the application needs to create some update statement,
say UPDATE foo SET a = entered_value;. So the application already knows
that foo is the table and a is the column. So if the
Peter Eisentraut [EMAIL PROTECTED] writes:
... So the application already knows
that foo is the table and a is the column. So if the application
wants to know about details on the column a, it can execute
SELECT whatever FROM pg_attribute, pg_class WHERE relname = 'foo' AND attname = 'a';
Tom Lane writes:
Yes, Dave did answer --- basically, he's happy with not providing any
column identity data in the cases where it's not obvious what the answer
should be. And in particular he doesn't want the mechanism to drill
down into view definitions (which is less than obviously right
Tom Lane kirjutas R, 14.03.2003 kell 19:15:
Greg Stark [EMAIL PROTECTED] writes:
So, just to throw out a wild idea: If you're talking about making large
changes to the on-the-wire protocol. Have you considered using an existing
database protocol?
Yeah, I have. Didn't look promising ---
Justin Clift wrote:
[ ... ]
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.
And
Tom Lane wrote:
Barry Lind [EMAIL PROTECTED] writes:
The describe request is generally only
done once even though you may do multiple fetchs (unlike todays protocol
which includes the describe information on every fetch, even if you are
fetching one row at a time).
I'm less than excited about
Christof Petig wrote:
If you know you are never interested in metadata, you can omit the
describe flag at all. [null indication and type specification is of
course always needed to access the actual data]
More exactly they are sent separately:
null indication is per row 'D'/'B' and type
for that, we get what exactly? Fetching one row at a time is
*guaranteed* to be inefficient. The correct response if that bothers
you is to fetch multiple rows at a time, not to make a less robust
protocol.
I don't feel strongly either way on this one, but IIRC the SQL standard
for
So, just to throw out a wild idea: If you're talking about making large
changes to the on-the-wire protocol. Have you considered using an existing
database protocol? This would avoid having to reinvent the wheel every time
postgres implements a new feature like prepared queries, bind arrays, or
Greg Stark [EMAIL PROTECTED] writes:
So, just to throw out a wild idea: If you're talking about making large
changes to the on-the-wire protocol. Have you considered using an existing
database protocol?
Yeah, I have. Didn't look promising --- there's no percentage unless
we're 100%
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Greg Stark) wrote:
So, just to throw out a wild idea: If you're talking about making large
changes to the on-the-wire protocol. Have you considered using an existing
database protocol? This would avoid having to reinvent the wheel
Tom Lane writes:
So are you voting against adding any attribute-ID info to
RowDescription? While I'm not that thrilled with it myself, it seems
relatively harmless as long as we can keep the overhead down. I'm
okay with attrelid/attnum, but would gripe about including more than that.
At
Peter Eisentraut [EMAIL PROTECTED] writes:
At the beginning of this thread you raised a number of points where the
identity of the column of origin is not well-defined. I haven't seen an
answer to that.
Yes, Dave did answer --- basically, he's happy with not providing any
column identity data
Tom Lane [EMAIL PROTECTED] writes:
Barry Lind [EMAIL PROTECTED] writes:
4) Protocol level support of PREPARE. In jdbc and most other
interfaces, there is support for parameterized SQL. If you want to take
advantage of the performance benefits of reusing parsed plans you have
to
Barry Lind wrote:
3) Protocol level support for CURSORs. It would be nice if cursor
support was done at the protocol level and not as a SQL command.
I want to second this proposal. Currently I avoid using cursors in my
programs since
a) they need much more logic and _string_concatenation_ to be
Tom Lane wrote:
Barry Lind [EMAIL PROTECTED] writes:
One addition I would personally like to see (it comes up in my apps
code) is the ability to detect wheather the server is big endian or
little endian. When using binary cursors this is necessary in order to
read int data.
Actually, my
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
Also doesn't the planner/executor already have all needed info available ?
Not directly, and not necessarily in the form that the client would want
it in (eg, converting type OID to type name isn't free). I don't care
to load either the
Barry Lind [EMAIL PROTECTED] writes:
AFAICS the only context where this could make sense is binary
transmission of parameters for a previously-prepared statement. We do
have all the pieces for that on the roadmap.
Actually it is the select of binary data that I was refering to. Are
you
Couldn't it be done optionally, so the clients that want the info pay the
price and those that don't want it get the speed and lower bandwidth?
Just a thought
andrew
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
Also
Tom Lane wrote:
Barry Lind [EMAIL PROTECTED] writes:
AFAICS the only context where this could make sense is binary
transmission of parameters for a previously-prepared statement. We do
have all the pieces for that on the roadmap.
Actually it is the select of binary data that I was refering to.
Barry Lind [EMAIL PROTECTED] writes:
Tom Lane wrote:
See binary cursors ...
Generally that is not an option. It either requires users to code to
postgresql specific sql syntax, or requires the driver to do it
magically for them.
Fair enough. I don't see anything much wrong with a GUC
Tom Lane wrote:
Barry Lind [EMAIL PROTECTED] writes:
Tom Lane wrote:
See binary cursors ...
Generally that is not an option. It either requires users to code to
postgresql specific sql syntax, or requires the driver to do it
magically for them.
Fair enough. I don't see anything much
-Original Message-
From: Hiroshi Inoue [mailto:[EMAIL PROTECTED]
Sent: 13 March 2003 10:04
To: Dave Page
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [HACKERS] Roadmap for FE/BE protocol redesign
Dave Page
-Original Message-
From: Zeugswetter Andreas SB SD [mailto:[EMAIL PROTECTED]
Sent: 13 March 2003 17:07
To: Hiroshi Inoue; Dave Page
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: RE: [HACKERS] Roadmap for FE/BE protocol redesign
If this where
It's rumoured that Hiroshi Inoue once said:
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
No, but with them we can avoid cluttering the wire protocol with
fields for all this, and the JDBC required data. With 2 numeric
columns (attrelid, attnum), any application/interface can query
Dave Page wrote:
It's rumoured that Hiroshi Inoue once said:
Tom Lane wrote:
"Dave Page" [EMAIL PROTECTED] writes:
No, but with them we can avoid cluttering the wire protocol with
fields for all this, and the JDBC required data. With 2 numeric
columns
Obviously there is cost, but doing a lookup only on demand, has got to be
cheaper in the long run than including the entire column definition in the
message whether it's wanted or not?
So if there are 100 fields, should we ask the backend
the column name 100 times ?
No, you do a single
Hiroshi Inoue kirjutas N, 13.03.2003 kell 12:03:
Dave Page wrote:
Does looking up by the catalog keys take no cost ?
Obviously there is cost, but doing a lookup only on demand, has got to be
cheaper in the long run than including the entire column definition in the
message whether
] Roadmap for FE/BE protocol redesign
Dave Page wrote:
It's rumoured that Hiroshi Inoue once said:
Does looking up by the catalog keys take no cost ?
Obviously there is cost, but doing a lookup only on demand,
has got to
be cheaper in the long run than including
Tom Lane wrote:
"Dave Page" [EMAIL PROTECTED] writes:
It's rumoured that Hiroshi Inoue once said:
Does looking up by the catalog keys take no cost ?
Obviously there is cost, but doing a lookup only on demand, has got to be
cheaper in the long run than including
Hiroshi Inoue [EMAIL PROTECTED] writes:
Hmm as for PREPAREd statements, it seems much better to
implement functions which returns fields info for the
statement than relying on such a protocol level change.
Well, we're changing the protocol anyway for other purposes, so the
extra burden of a
Marc G. Fournier wrote:
On Tue, 11 Mar 2003, Bruce Momjian wrote:
Six months would be June 1 beta, so maybe that is still a good target.
We released v7.3 just before Dec 1st, so six months is May 1st, not June
1st ...
Six months is June 1 --- December (1), January-May (5) == 6.
--
Dave Page wrote:
I don't know about JDBC, but ODBC could use it, and it would save a heck
of a lot of pain in apps like pgAdmin that need to figure out if a column
in an arbitrary resultset might be updateable.
At the moment there is some nasty code in pgAdmin II that attempts to
parse the SQL
I'm still unclear on exactly what your needs are. In the first place,
are you expecting to obtain data from arbitrary SELECT statements, or
only from statements of the form SELECT * FROM single_table? You've
also been confusing as to whether you want transparency of views (ie,
does a
:
-Original Message-
From: Zeugswetter Andreas SB SD [mailto:[EMAIL PROTECTED]
Sent: 12 March 2003 09:50
To: Hiroshi Inoue; Tom Lane
Cc: Bruce Momjian; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [HACKERS] Roadmap for FE/BE protocol redesign
The ODBC function SQLDescribeCol
Barry Lind [EMAIL PROTECTED] writes:
One addition I would personally like to see (it comes up in my apps
code) is the ability to detect wheather the server is big endian or
little endian. When using binary cursors this is necessary in order to
read int data.
Actually, my hope is to
Peter Eisentraut writes:
Dave Page writes:
Well what I *really* need has been made quite clear in other posts,
but,
when I say resultset in the same sentence as pgAdmin, I'm referring
to
the ability to enter an arbitrary SQL query, have the results
displayed
in a grid, which can then
One addition I would personally like to see (it comes up in my apps
code) is the ability to detect wheather the server is big endian or
little endian. When using binary cursors this is necessary in order to
read int data.
Actually, my hope is to eliminate that business entirely by
Tom Lane kirjutas K, 12.03.2003 kell 18:19:
Barry Lind [EMAIL PROTECTED] writes:
One addition I would personally like to see (it comes up in my apps
code) is the ability to detect wheather the server is big endian or
little endian. When using binary cursors this is necessary in order to
One addition I would personally like to see (it comes up in my
apps code) is the ability to detect wheather the server is big
endian or little endian. When using binary cursors this is
necessary in order to read int data.
Actually, my hope is to eliminate that business entirely by
Hannu Krosing wrote:
Tom Lane kirjutas K, 12.03.2003 kell 18:19:
Actually, my hope is to eliminate that business entirely by
standardizing the on-the-wire representation for binary data; note the
reference to send/receive routines in the original message. For integer
data this is simple enough:
Peter Eisentraut wrote:
Dave Page writes:
Well what I *really* need has been made quite clear in other
posts, but, when I say resultset in the same sentence as
pgAdmin, I'm referring to the ability to enter an arbitrary
SQL query, have the results displayed in a
I suggested using names to Tom for this reason, but he preferred to use
attrelid/attnum.
Oh, and what happenned to the attlognum idea? If something that needs
it is going to be implemented the column should probably be added now
and used instead of attnum.
Wll, it'd be nice, but I
On Wed, 2003-03-12 at 20:45, Hiroshi Inoue wrote:
Peter Eisentraut wrote:
Dave Page writes:
Well what I *really* need has been made quite clear in other
posts, but, when I say resultset in the same sentence as
pgAdmin, I'm referring to the ability to enter an arbitrary
SQL
I agree, let's not wait for specific features. The issue was whether we
had enough significant features done for a release --- I didn't think we
did, so I am saying, let's get more features, rather than let's get
feature X.
As we fill in missing features, there will be less must-have features
Justin Clift wrote:
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.
I'd like to help. I've been following the list for several
Hiroshi Inoue [EMAIL PROTECTED] writes:
What the driver has suffered from is to get the
fields' info of a query result or the parameters'
info of a statement. The info is needed even before
the execution of the statement(i.e it's only prepared).
Hm. Are you saying that you would like PREPARE
If there's a build of this available we'd love to test it in a major project
we're working on. The project is currently using the 7.2 build that was made
available, but we had to work around the lack of schema support by kludging
table names as namespace_table, so a 7.3 build would be great, with
Sure, Neil Conway updated Jan's patches for 7.3. It is in:
ftp://candle.pha.pa.us/pub/postgresql/mypatches/
---
Merlin Moncure wrote:
Justin Clift wrote:
confidentiality level of the Win32/PITR patches at
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
Well, what would constitute a complete spec? I think I've told the group
what I would like to be able to do, what unanswered questions can I
(hopefully :-) ) answer?
I'm still unclear on exactly what your needs are. In the first place,
On Mon, 10 Mar 2003, 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
Marc G. Fournier 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
Kevin Brown [EMAIL PROTECTED] writes:
doing more or less what other database vendors have done in response
to these underspecified issues is probably a sensible course of action
when there's no other obviously better answer.
A good point, indeed. Who wants to do the legwork to check up on
It's rumoured that Tom Lane once said:
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
It's rumoured that Bruce Momjian once said:
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,
It's rumoured that Bruce Momjian once said:
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
Tom Lane wrote:
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
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
Tom Lane wrote:
snip
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
+ 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
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)
* 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
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
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
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.
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
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
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
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
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,
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
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
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
Bruce Momjian wrote:
snip
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
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
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
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
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:
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,
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
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
84 matches
Mail list logo
