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
[7.3.2 on debian unstable]
We recently had an unclean server shutdown and now a pg_dump command
crashes the backend:
pg_dump: PANIC: open of /var/lib/postgres/data/pg_clog/0003 failed: No
such file or directory
Should we restore from a known good dump after an initdb?
--
PHEDRE:
On Thursday 13 March 2003 20:51, Tom Lane wrote:
(Or, protocol upgrade phase 1...)
After digging through our many past discussions of what to do with error
messages, I have put together the following first-cut proposal. Fire at
will...
Objective
-
The basic objective here is to
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
Darko Prenosil [EMAIL PROTECTED] writes:
What about user messages ?
If I remember correct, MSSQL had a system catalog table with formated error
messages, and it was possible to raise error with error number and it's
parameters. It can be very useful when you must raise same error from
-*- Tom Lane [EMAIL PROTECTED] [ 2003-03-14 15:33 ]:
Darko Prenosil [EMAIL PROTECTED] writes:
What about user messages ?
If I remember correct, MSSQL had a system catalog table with formated error
messages, and it was possible to raise error with error number and it's
parameters. It
On Thu, Mar 13, 2003 at 03:51:00PM -0500, Tom Lane wrote:
Wire-protocol changes
-
Error and Notice (maybe also Notify?) msgs will have this structure:
E
x string \0
x string \0
x string \0
\0
where the x's are single-character field
On 13 Mar 2003, Greg Stark wrote:
Joe Conway [EMAIL PROTECTED] writes:
I'm leaning toward implode() and explode() now anyway because split() uses a
regex for the delimiter in PHP (and probably Perl), and I was not planning to
get that fancy.
PHP isn't exactly an exemplar for great
Louis-David Mitterrand [EMAIL PROTECTED] writes:
[7.3.2 on debian unstable]
We recently had an unclean server shutdown and now a pg_dump command
crashes the backend:
pg_dump: PANIC: open of /var/lib/postgres/data/pg_clog/0003 failed: No
such file or directory
Should we restore from a known
Hackers,
I talked to Bruce and I've chosen a project, which will be nested
transactions and hopefully savepoints. I have started reading previous
discussion on the topic, and looking at the code to see what's involved.
AFAICT, transaction mechanisms and states is the first thing to visit
(eg.
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%
johnn [EMAIL PROTECTED] writes:
It would seem to make more sense to me to provide a different
function(s) which allows the lookup Messages, Details, and Hints based
on the SQLSTATE.
This would constrain us to have a different SQLSTATE for every error
message, which we aren't going to do.
scott.marlowe [EMAIL PROTECTED] writes:
You're quick to throw out a trollish barb against PHP without any
real discussion as to why it's such a horrible language.
No need to be so sensitive. It was just a humorous way of making the point
that just because PHP does something doesn't mean
On 14 Mar 2003, Greg Stark wrote:
scott.marlowe [EMAIL PROTECTED] writes:
You're quick to throw out a trollish barb against PHP without any
real discussion as to why it's such a horrible language.
No need to be so sensitive. It was just a humorous way of making the point
that just
Do you really think someone looking for a function to break up a
string into a list of strings would ever think of looking up explode
in an index if he hadn't already used PHP or (shudder) VBScript?
It's also one of the classic examples of things used in introductory
courses on Lisp that are
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] [ 2003-03-14 17:43 ]:
Do you really think someone looking for a function to break up a string into a
list of strings would ever think of looking up explode in an index if he
hadn't already used PHP or (shudder) VBScript?
If one had gotten used to Lotus Notes,
On Fri, 2003-03-14 at 12:14, Alvaro Herrera wrote:
Hackers,
I talked to Bruce and I've chosen a project, which will be nested
transactions and hopefully savepoints. I have started reading previous
discussion on the topic, and looking at the code to see what's involved.
...
don't expect
On Fri, Mar 14, 2003 at 12:23:04PM -0500, Tom Lane wrote:
It would seem to make more sense to me to provide a different
function(s) which allows the lookup Messages, Details, and Hints
based on the SQLSTATE.
This would constrain us to have a different SQLSTATE for every error
message,
On Fri, 14 Mar 2003, Christopher Browne wrote:
Do you really think someone looking for a function to break up a
string into a list of strings would ever think of looking up explode
in an index if he hadn't already used PHP or (shudder) VBScript?
It's also one of the classic examples of
On Fri, 14 Mar 2003, Þórhallur Hálfdánarson wrote:
-*- Greg Stark [EMAIL PROTECTED] [ 2003-03-14 17:43 ]:
Do you really think someone looking for a function to break up a string into a
list of strings would ever think of looking up explode in an index if he
hadn't already used PHP or
Here's a list of synonyms for join (courtesy of m-w.com):
associate, bracket, coadunate, coagment, coalesce, combine, compound,
concrete, conjoin, conjugate, connect, couple, link, marry, one, relate,
unite, wed, yoke
and for split:
carve, cleave, dissect, dissever, sever, slice, sunder,
johnn [EMAIL PROTECTED] writes:
If it's different enough to warrant a different message, then, in my
mind, it's different enough to warrant a different SQLSTATE.
Unfortunately, you're at odds with the SQL spec authors, who have made
their intentions pretty clear by defining only about 130
scott.marlowe [EMAIL PROTECTED] writes:
On Fri, 14 Mar 2003, Þórhallur Hálfdánarson wrote:
-*- Greg Stark [EMAIL PROTECTED] [ 2003-03-14 17:43 ]:
Do you really think someone looking for a function to break up a string into a
list of strings would ever think of looking up explode in an
On 14 Mar 2003, Jason Earl wrote:
It's all good Scott. Anyone wanting to use PostgreSQL arrays would
undoubtedly open up the corresponding part of the manual that covers
array functions. Since there is likely to be less than a page full of
function definitions you could probably call the
Same setup, different query:
test= explain select max(time) from test where id = '1';
NOTICE: QUERY PLAN:
Aggregate (cost=5084.67..5084.67 rows=1 width=0)
- Index Scan using idx on test (cost=0.00..5081.33 rows=1333 width=0)
Since the index is (id, time), why isn't the index being used to
Jason Earl wrote:
Actually, I think it was someone else (Joe???) that is doing the leg
work, and he was the one choosing explode / implode and getting
gruff for it, so I was just stepping in and defending his decision.
Oops, my bad. My brain must already think that it is the weekend. My
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
Tom Lane writes:
Error and Notice (maybe also Notify?) msgs will have this structure:
E
x string \0
x string \0
x string \0
\0
where the x's are single-character field identifiers.
I think we need more flexible field tags. The SQL standards has
provisions
Some people were mentioning an error message style guide. Here's a start
of one that I put together a while ago. Feel free to consider it.
Size of message
---
The main part of a message should be at most 72 characters long. For
embedded format specifiers (%s, %d, etc.), a
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
where the x's are single-character field identifiers.
I think we need more flexible field tags. The SQL standards has
provisions for more fields accompanying error messages, such as the name
of the affected table.
Well, we can
One thing that would be great from a user's perspective (and which might
reduce the volume of support questions as well) is to uniquely number all
errors as in:
Error 1036: the foo could not faz the fleep
The advantages of this include:
Ease of documentation: a manual could containg a section
Taral [EMAIL PROTECTED] writes:
On Thu, Mar 13, 2003 at 10:30:27PM -0500, Tom Lane wrote:
The idea is you look at the index to make a list of main-table tuple
positions you are interested in, which you represent compactly as a
compressed bitmap. [snip]
And it loses bigtime in the case of
On Fri, Mar 14, 2003 at 10:43:30PM -0500, Tom Lane wrote:
Sure. That's why we have a planner that distinguishes between startup
cost and total cost, and interpolates when a LIMIT is involved. But
if this mergesort idea only helps for small-limit cases, that's another
restriction on its scope
I said:
I had missed the relevance of condition information item name, will
go look at it.
It looks to me like support of the SQL condition information items would
require adding about two dozen optional fields to my spec for the Error
protocol message, and the same number of optional
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
On Friday 14 March 2003 13:24, scott.marlowe wrote:
I vote for explode / implode as easier to type and remember than join_str.
Also, in the SQL world, it's very likely that a back ground in
ADA/LISP/REX/PHP is just as common as Perl or Java.
If we're voting I vote for join/split. Implode and
On Fri, 14 Mar 2003, D'Arcy J.M. Cain wrote:
On Friday 14 March 2003 13:24, scott.marlowe wrote:
I vote for explode / implode as easier to type and remember than join_str.
Also, in the SQL world, it's very likely that a back ground in
ADA/LISP/REX/PHP is just as common as Perl or Java.
Added to TODO:
* Add GUC log_statement_duration to print statement and = min duration
---
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
One nice thing is that each element is
41 matches
Mail list logo
