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
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
[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: Malheure
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
> > 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
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
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
> > param
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-chara
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
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
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. ne
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
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 d
"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 me
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 poin
> 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 a
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 No
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 exp
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
> mes
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 exam
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 PH
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, cleave
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 13
"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
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
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> 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
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 t
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
reasoning
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
pro
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 reasonab
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
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 di
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 c
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 sc
I said:
> I had missed the relevance of , 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 errFOO(...)
subroutines in the ereport(
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
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 an
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 Jav
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 eleme
42 matches
Mail list logo
