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. (There is some finagling needed because PG actually
> uses block/line number r
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Would it be possible to do a command line app?
>
> bash$ pg_error 1200D
> Severity: ERROR
> Message: Division by zero
> Detail:
> Hint: Modify statement to prevent zeros appearing in denominators.
You're assuming that there's a one-to-one ma
Taral <[EMAIL PROTECTED]> writes:
> On Thu, Mar 13, 2003 at 04:28:34PM -0500, Tom Lane wrote:
>> Seems like a waste of effort to me. I find this example less than
>> compelling --- the case that could be sped up is quite narrow,
>> and the potential performance gain not all that large. (A sort
>>
> On Thu, 2003-03-13 at 21:16, Christopher Kings-Lynne wrote:
> > Would it be possible to do a command line app?
> >
> > bash$ pg_error 1200D
> > Severity: ERROR
> > Message: Division by zero
> > Detail:
> > Hint: Modify statement to prevent zeros appearing in denominators.
>
> Is there any benefit
On Thu, 2003-03-13 at 21:16, Christopher Kings-Lynne wrote:
> Would it be possible to do a command line app?
>
> bash$ pg_error 1200D
> Severity: ERROR
> Message: Division by zero
> Detail:
> Hint: Modify statement to prevent zeros appearing in denominators.
Is there any benefit to having this ov
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.
--
> Great work, Tom!
>
> While we're effectively changing every elog call site in the backend,
> would it also be a good idea to adopt a standard for the format of error
> messages? (e.g. capitalization, grammar, etc.)
I 100% agree with this - a style guide!
Chris
---(end
> Comments?
All the error stuff sounds really neat. I volunteer for doing lots of elog
changes when the time comes.
Would it be possible to do a command line app?
bash$ pg_error 1200D
Severity: ERROR
Message: Division by zero
Detail:
Hint: Modify statement to prevent zeros appearing in denomina
> implode(text[], text) returns text - join array elements into a
> string using given string delimiter
>
> I'm open to opinions on implode() -- I only picked implode() because
> that's what it is called in PHP. Any suggestions?
It's also called 'join' in PHP...
Chris
---
On Thu, Mar 13, 2003 at 04:28:34PM -0500, Tom Lane wrote:
> Seems like a waste of effort to me. I find this example less than
> compelling --- the case that could be sped up is quite narrow,
> and the potential performance gain not all that large. (A sort
> is a sort however you slice it, with O(
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
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 language design.
explode/implode are te
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
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Hmmm -- I doubt that would fly, although I see it is specifically
allowed as a function name (func_name_keyword list). Anyone have
opinions on this either way?
Good point --- it would work today, but any small tweak in the JOIN
grammar might
Joe Conway <[EMAIL PROTECTED]> writes:
>> In both Perl and Python, that type of function is called "join".
> Hmmm -- I doubt that would fly, although I see it is specifically
> allowed as a function name (func_name_keyword list). Anyone have
> opinions on this either way?
Good point --- it woul
Jean-Luc Lachance <[EMAIL PROTECTED]> writes:
> Why trade 5 characters for a 4 byte integer -- a saving of 1 byte?
It's more than that: in one case you have something on the order of
a "load immediate" instruction, whereas in the other case the code
is like "load pointer to global string", plus yo
Neil Conway <[EMAIL PROTECTED]> writes:
> While we're effectively changing every elog call site in the backend,
> would it also be a good idea to adopt a standard for the format of error
> messages? (e.g. capitalization, grammar, etc.)
Yup. I was planning to bring that up as a separate thread. I
> -Original Message-
> From: Dave Page
>
> > -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]
> > Sub
On Thu, 2003-03-13 at 15:51, Tom Lane wrote:
> After digging through our many past discussions of what to do with error
> messages, I have put together the following first-cut proposal.
Great work, Tom!
While we're effectively changing every elog call site in the backend,
would it also be a good
--On Thursday, March 13, 2003 16:20:21 -0500 Tom Lane <[EMAIL PROTECTED]>
wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
__FUNCTION__ or an equivalent is MANDATED by C99, and available on
UnixWare's native cc.
You might want to make a configure test for it.
Right, __func__ is the C99 spellin
Taral <[EMAIL PROTECTED]> writes:
> Do I need to code merge sort into postgresql?
Seems like a waste of effort to me. I find this example less than
compelling --- the case that could be sped up is quite narrow,
and the potential performance gain not all that large. (A sort
is a sort however you
Larry Rosenman <[EMAIL PROTECTED]> writes:
> __FUNCTION__ or an equivalent is MANDATED by C99, and available on
> UnixWare's native cc.
> You might want to make a configure test for it.
Right, __func__ is the C99 spelling. I did have a configure test in
mind here: __func__ or __FUNCTION__ or NUL
--On Thursday, March 13, 2003 15:51:00 -0500 Tom Lane <[EMAIL PROTECTED]>
wrote:
(__FUNCTION__ is only used if we are compiling in gcc). errstart() pushes
an empty entry onto an error-data-collection stack and fills in the
behind-the-scenes file/line entries. errmsg() and friends stash value
I tried general, but no response. Anyone here can shed some light on the
issue? Do I need to code merge sort into postgresql?
- Forwarded message from Taral <[EMAIL PROTECTED]> -
From: Taral <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Wed, 12 Mar 2003 17:54:35 -0600
Subject: [GENERAL]
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Tom Lane kirjutas N, 13.03.2003 kell 19:12:
>>> The standard spelling for that appears to be
>>> somearray || ARRAY[element]
>>> which also has the nice property that it is commutative.
>>
>> Sure ... but that just means that || is the operator name for
Tom Lane kirjutas N, 13.03.2003 kell 19:12:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > OK, let's look at these more closely:
>
> >> array_push(anyarray, anyelement) returns anyarray
>
> > The standard spelling for that appears to be
> > somearray || ARRAY[element]
> > which also has t
(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 divide error reports into multiple
fields, and in partic
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
On Thu, 2003-03-13 at 12:53, Joe Conway wrote:
> Peter Eisentraut wrote:
> array_pop(anyarray) returns anyelement
> >
> > That appears to mean that you return somearray[0] and alter the array
> > as a side effect. How do you plan to do that?
>
> I'll give you this one -- doesn't make sense.
> -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 a
> I am working my way through getting the postgres win32 port (7.2.1)
> compiled under MSVC. I got through the patch and the compilation, but
> am having problems with the linker. Trying to link the backend, I get
> 43 linker errors like:
> unresolved external symbol GUC-scanstr
> unresolved exte
> -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
>
>
>
I am working my way through getting the postgres win32 port (7.2.1)
compiled under MSVC. I got through the patch and the compilation, but
am having problems with the linker. Trying to link the backend, I get
43 linker errors like:
unresolved external symbol GUC-scanstr
unresolved external symbol
Alvaro Herrera wrote:
Yeah, and join is also consistent with the inverse function being called
"split". IIRC the equivalent function in PHP is explode().
Actually it looks like PHP supports both explode() and split(), and
their inverse functions implode() and join(). split() appears to split
the
johnn wrote:
On Thu, Mar 13, 2003 at 09:53:15AM -0800, Joe Conway wrote:
implode(text[], text) returns text - join array elements into a
string using given string delimiter
In both Perl and Python, that type of function is called "join".
Hmmm -- I doubt that would fly, although I see it is spec
On Thu, Mar 13, 2003 at 12:00:46PM -0600, johnn wrote:
> On Thu, Mar 13, 2003 at 09:53:15AM -0800, Joe Conway wrote:
> > implode(text[], text) returns text - join array elements into a
> > string using given string delimiter
> >
> > I'm open to opinions on implode() -- I only picked im
On Thu, Mar 13, 2003 at 09:53:15AM -0800, Joe Conway wrote:
> implode(text[], text) returns text - join array elements into a
> string using given string delimiter
>
> I'm open to opinions on implode() -- I only picked implode() because
> that's what it is called in PHP. Any suggestions?
Peter Eisentraut wrote:
array_pop(anyarray) returns anyelement
That appears to mean that you return somearray[0] and alter the array
as a side effect. How do you plan to do that?
I'll give you this one -- doesn't make sense.
split(text, text) returns text[] - split string into array on
delimiter
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
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> OK, let's look at these more closely:
>> array_push(anyarray, anyelement) returns anyarray
> The standard spelling for that appears to be
> somearray || ARRAY[element]
> which also has the nice property that it is commutative.
Sure ... but that
Manfred Koizar <[EMAIL PROTECTED]> writes:
> ISTM you have found a Postgres 7.3 bug.
Yeah. Actually, the planner bug has been there a long time, but it was
only latent until the parser stopped suppressing duplicate GROUP BY
items:
2002-08-18 14:46 tgl
* src/backend/parser/parse_clause.
OK, let's look at these more closely:
> >> array_push(anyarray, anyelement) returns anyarray
The standard spelling for that appears to be
somearray || ARRAY[element]
which also has the nice property that it is commutative.
> >> array_pop(anyarray) returns anyelement
That appears
>
> On Tue, 4 Nov 2003 18:28:12 -0300, Franco Bruno Borghesi
> <[EMAIL PROTECTED]> wrote:
> >Below you can find a simplified example of a real case.
> >I don't understand why I'm getting the "john" record twice.
>
> ISTM you have found a Postgres 7.3 bug.
>
> I get one john with
> PostgreSQL 7.1.3
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
Thought I would change the title to see if anyone would respond?
It wasn't clear but the intent was to support the following in the
backend.
On Tue, 2003-03-11 at 18:20, Dave Cramer wrote:
> I have a customer porting an application from informix to postgres. They
> require 2 things:
>
> 1) Curs
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
[forwarding to -hackers]
On Tue, 4 Nov 2003 18:28:12 -0300, Franco Bruno Borghesi
<[EMAIL PROTECTED]> wrote:
>Below you can find a simplified example of a real case.
>I don't understand why I'm getting the "john" record twice.
ISTM you have found a Postgres 7.3 bug.
I get one john with
Postgr
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
It's rumoured that Christopher Kings-Lynne once said:
> When I create a new table with a serial column, the first row defaults
> to inserting '1'.
>
> If I delete all the rows from the table and want to reset the sequence,
> I can't:
>
> ERROR: users_health_types_type_id_seq.setval: value 0 is out
57 matches
Mail list logo
