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 r
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
> > > databas
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
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 righ
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 prom
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 t
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
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
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
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% compat
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
me
> > 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
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 specifica
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 abou
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.
--
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 w
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
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
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
ED]; [EMAIL PROTECTED];
> > [EMAIL PROTECTED]
> > Subject: Re: [HACKERS] Roadmap for FE/BE protocol redesign
> >
> >
> > Dave Page wrote:
> > >
> > > It's rumoured that Hiroshi Inoue once said:
> > > >
> > > > Does looking up b
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
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:
> > A
> -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
> -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
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. A
"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 ba
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
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 <[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 h
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
> > mes
> > 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
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
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/int
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: n
> > 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 entirel
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 o
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 arbit
> > 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
> > 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, b
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 displa
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 c
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 e
:
> > -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 prot
> > 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,
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 st
* 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 set
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
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
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
> will
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
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, wit
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 PR
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 pre
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 mo
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
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 ta
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 c
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 th
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
Hi guys,
As a thought, has anyone considered if it's worth doing data compression
of the "new proposed" protocol for PostgreSQL 8.0/7.4? It was suggested
a long time ago by Joshua Drake (and his version was well accepted by
his customers from what I heard), so might this be worth adding too?
Tom Lane wrote:
"Dave Page" <[EMAIL PROTECTED]> writes:
What about the addition of pg_attribute.attrelid &
pg_attribute.attname/attnum in RowDesription messages to identify the
underlying attribute (where appropriate)?
Well, we can talk about it, but I still think that any frontend that
relies on
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I was willing to add a hack to enable default column labels to be
> > "table.column" --- that seemed like the least obtrusive.
>
> Most of the definitional issues still apply: which table name are you
> going to insert, and under what
> I had been leaning to May 1 beta, but am happy to switch to June 1 if
> you feel that makes an improvement in the odds of completing the Windows
> port. (I think it will also improve the odds of finishing this protocol
> stuff I've taken on...) I don't want to see it pushed further than that
>
Bruce Momjian wrote:
So, what should we do? Should we go another month or two and just wait
until we have enough must-have features? While not waiting on specific
features, it _is_ waiting for something to warrant a release. I guess
the big question is whether we release on a scheduled-basis or
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I was willing to add a hack to enable default column labels to be
> "table.column" --- that seemed like the least obtrusive.
Most of the definitional issues still apply: which table name are you
going to insert, and under what conditions?
If we're revis
Tom Lane wrote:
> "Dave Page" <[EMAIL PROTECTED]> writes:
> > What about the addition of pg_attribute.attrelid &
> > pg_attribute.attname/attnum in RowDesription messages to identify the
> > underlying attribute (where appropriate)?
>
> Well, we can talk about it, but I still think that any fronte
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2003-03-10 at 16:37, Ashley Cambrell wrote:
>> This would also get around the problem of getting values from newly
>> inserted rows (eg PKs) without resorting to OIDs.
> That's not a problem: ensure that the newly inserted row has a SERIAL
> colum
Neil Conway wrote:
On Mon, 2003-03-10 at 16:37, Ashley Cambrell wrote:
This would also get around the problem of getting values from newly
inserted rows (eg PKs) without resorting to OIDs.
That's not a problem: ensure that the newly inserted row has a SERIAL
column, and
On Mon, 2003-03-10 at 16:37, Ashley Cambrell wrote:
> This would also get around the problem of getting values from newly
> inserted rows (eg PKs) without resorting to OIDs.
That's not a problem: ensure that the newly inserted row has a SERIAL
column, and use currval().
Cheers,
Neil
--
Neil C
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
Tom Lane wrote:
This is an attempt to lay out a road map for updating the frontend/backend
protocol in 7.4. I don't at this point want to get into details on any
one of the TODO items, just get consensus that this is the set of tasks
to be tackled. Are there any areas that I've missed (that requ
Rod Taylor <[EMAIL PROTECTED]> writes:
>> We already have that: you send a startup packet with a version less than
>> the latest, and the backend speaks that version to you.
> Yes, but that requires you know the backend is less than the latest.
As opposed to knowing what? You send the version nu
Justin Clift wrote:
>
> PostgreSQL 8.0
> **
>
> + Includes PITR and the Win32 port
*snip*
I feel like the upcoming 7.4 is the most important release since the
introduction of toast, maybe even since the introduction of the sql
language. I wholeheartedly agree with your proposition.
On Mon, 2003-03-10 at 14:30, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > I'd be tempted to make a startup packet that will allow libpq to revert
> > back to old protocols easily enough for the future so that we can do=20
> > incremental changes to the protocol.
>
> We already have
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
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> * Backend should pass its version number, database encoding, default
>> client encoding, and possibly other data (any ideas?) to frontend during
>> startup, to avoid need for explicit queries to get this info.
> Should we pass this in
> * Backend's ReadyForQuery message (Z message) should carry an indication
> of current transaction status (idle/in transaction/in aborted transaction)
> so that frontend need not guess at state. Perhaps also indicate
> autocommit status. (Is there anything else that frontends would Really
> Like
Justin Clift <[EMAIL PROTECTED]> writes:
> The scenario that's appealing to me the most is this for the next release:
> PostgreSQL 8.0
> + Includes PITR and the Win32 port
If the folks doing those things can get done in time, great. I'm even
willing to push out the release schedule (now, not late
Tom Lane wrote:
> * Backend should pass its version number, database encoding, default
> client encoding, and possibly other data (any ideas?) to frontend during
> startup, to avoid need for explicit queries to get this info. We could
> also consider eliminating SET commands sent by libpq in favor
> + Not sure where Satoshi is up to with his 2 phase commit proposal, but
> that might make sense to incorporate into a wire protocol revision.
> From memory he received funding to work on it, so it might be coming
> along nicely.
One should note that his protocol changes had absolutely nothin
Tom Lane wrote:
One way to tamp down expectations of client backwards compatibility
would be to call the release 8.0 instead of 7.4 ;-)
Comments?
Actually, I've been thinking about the numbering of the next PostgreSQL
version for a few days now.
The scenario that's appealing to me the most is th
83 matches
Mail list logo