For the next release and package it would be good to differentiate the
release candidate to the proper release. (7.2.1 had the same name and it can
be confusing). a suffix postgresql-7.3-RCN.tar.gz is enough to make the
difference between different verisons of release candidates and the final
rele
Christopher Kings-Lynne wrote:
>>Is anyone feeling we have the 7.3 release nearing?
>>
>
>No way!
>
>>I certainly am not.
>>I can imagine us going for several more months like this, perhaps
>>through August.
>>
>
>Easily. I think that the critical path is Tom's schema support.
>
>We'll need a g
Fernando Nasser wrote:
>
> Hiroshi Inoue wrote:
> >
> > Fernando Nasser wrote:
> > >
> > > As most things in the SQL standard, you have to collect information
> > > from several places and add it together.
> > >
> > > Look at 4.20, 11.1 and specially at the rules for
> > > .
> > >
> > > Then think
OK. My mistake. In looking at the regression failures in your post, I
thought I saw errors being reported of this type. My bad.
--Barry
Tom Lane wrote:
> Barry Lind <[EMAIL PROTECTED]> writes:
>
>>My feeling is that this change as currently scoped will break a lot of
>>existing apps. Espe
Neil,
Will this allow you to pass bytea data as binary data in the parameters
section (ability to bind values to parameters) or will this still
require that the data be passed as a text string that the parser needs
to parse. When passing bytea data that is on the order of Megs in size
(thus
Barry Lind <[EMAIL PROTECTED]> writes:
> My feeling is that this change as currently scoped will break a lot of
> existing apps. Especially the case where people are using where clauses
> of the form: bigintcolumn = '999' to get a query to use the index on
> a column of type bigint.
Eh? T
Tom,
My feeling is that this change as currently scoped will break a lot of
existing apps. Especially the case where people are using where clauses
of the form: bigintcolumn = '999' to get a query to use the index on
a column of type bigint.
thanks,
--Barry
Tom Lane wrote:
> Awhile back
Christopher Kings-Lynne wrote:
> > Is anyone feeling we have the 7.3 release nearing?
>
> No way!
Good.
> > I certainly am not.
> > I can imagine us going for several more months like this, perhaps
> > through August.
>
> Easily. I think that the critical path is Tom's schema support.
>
> W
> Is anyone feeling we have the 7.3 release nearing?
No way!
> I certainly am not.
> I can imagine us going for several more months like this, perhaps
> through August.
Easily. I think that the critical path is Tom's schema support.
We'll need a good beta period this time, because of:
* Sch
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > Hiroshi Inoue wrote:
> > > If the client has to bear the some part, isn't the invisible
> > > column approach much simpler ?
> > >
> > > I've put a pretty much time into DROP COLUMN feature but
> > > I am really disappointed to see the comments
On Wed, 10 Apr 2002, Neil Conway wrote:
> Hi all,
>
> I'm working on a fairly large patch (cleaning up Karel Zak's
> PREPARE/EXECUTE work), and I'm having some problems with bison (I'm
> a yacc newbie). In fact, my grammar currently has an obscene
> 20 shift/reduce and 4 reduce/reduce conflicts!
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > If the client has to bear the some part, isn't the invisible
> > column approach much simpler ?
> >
> > I've put a pretty much time into DROP COLUMN feature but
> > I am really disappointed to see the comments in this thread.
> > What DROP COLUMN h
Thomas Lockhart writes:
> 1) All commands starting with "SET" must have the same transactional
> semantics. I'll agree that it might be nice for consistancy, but imho is
> not absolutely required.
This rule is already violated anyway. SET TRANSACTION ISOLATION, SET
CONSTRAINTS, SET SESSION AUTH
Is anyone feeling we have the 7.3 release nearing? I certainly am not.
I can imagine us going for several more months like this, perhaps
through August.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is
Hiroshi Inoue wrote:
> > It seems to me that whatever we do
> > will require some kind of client breakage.
>
> Physical/logical attnum approach was mainly to not break
> clients. I implemented it on trial but the implementation
> was hard to maintain unfortunately. It's pretty difficult
> to deci
Christopher Kings-Lynne wrote:
>
> > If the client has to bear the some part, isn't the invisible
> > column approach much simpler ?
> >
> > I've put a pretty much time into DROP COLUMN feature but
> > I am really disappointed to see the comments in this thread.
> > What DROP COLUMN has brought me
__
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Christopher Kings-Lynne wrote:
> > Actually, what we need to do to reclaim space is to enable table
> > recreation without the column, now that we have relfilenode for file
> > renaming. It isn't hard to do, but no one has focused on it. I want to
> > focus on it, but have not had the time, obvi
Bear Giles <[EMAIL PROTECTED]> writes:
>> Yes: if the lexer folds them together then unreserved_keyword can't
>> regenerate the equivalent name properly.
> But if they're synonyms, is that necessary?
If I say
create table foo (temp int);
I will be annoyed if the system decides that the c
> Actually, what we need to do to reclaim space is to enable table
> recreation without the column, now that we have relfilenode for file
> renaming. It isn't hard to do, but no one has focused on it. I want to
> focus on it, but have not had the time, obviously, and would be very
> excited to a
Christopher Kings-Lynne wrote:
> > If the client has to bear the some part, isn't the invisible
> > column approach much simpler ?
> >
> > I've put a pretty much time into DROP COLUMN feature but
> > I am really disappointed to see the comments in this thread.
> > What DROP COLUMN has brought me s
Hiroshi Inoue wrote:
> If the client has to bear the some part, isn't the invisible
> column approach much simpler ?
>
> I've put a pretty much time into DROP COLUMN feature but
> I am really disappointed to see the comments in this thread.
> What DROP COLUMN has brought me seems only a waste of
> If the client has to bear the some part, isn't the invisible
> column approach much simpler ?
>
> I've put a pretty much time into DROP COLUMN feature but
> I am really disappointed to see the comments in this thread.
> What DROP COLUMN has brought me seems only a waste of time.
I kind of agree
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > > > Why ? As you already mentioned, there were not that many places
> > > > to be changed.
> > > >
> > > > Well what's changed since then ?
> > >
> > > Here is an old email from me that outlines the idea of having a
> > > physical/logical attribute
> > As an aside, is there any reason to treat TEMP and TEMPORARY as two
> > separate identifiers?
>
> Yes: if the lexer folds them together then unreserved_keyword can't
> regenerate the equivalent name properly.
But if they're synonyms, is that necessary? I'm not indifferent to the
benefits of
Bear Giles <[EMAIL PROTECTED]> writes:
> As an aside, is there any reason to treat TEMP and TEMPORARY as two
> separate identifiers?
Yes: if the lexer folds them together then unreserved_keyword can't
regenerate the equivalent name properly. (Possibly this could be fixed
by making the lexer pass
> PREPARE AS ;
> EXECUTE USING ;
> DEALLOCATE ;
>
> I didn't write the original patch -- that was done by Karel Zak.
> But since that was several years ago, I'm working on cleaning it up,
> getting it to apply to current sources (which has taken a while),
> and fixing the remaining issues with i
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Since it's really just two ways of writing the same thing, wouldn't bison
> just produce the exact same C code? I'll rewrite it anyway for elegance,
> but just wondering...
The emitted code might or might not be the same --- but duplicate o
On Thu, 11 Apr 2002 10:54:14 +0800
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> wrote:
> Out of interest, since the FE/BE protocol apprently doesn't support prepared
> statements (bound variables), what does this patch actually _do_?
It implements preparable statements, by adding 3 new SQL state
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > Also, Tom (or anyone): in regards to your previous email,
> should I just go
> > back to using opt_symmetry to shorten the number of productions, since I
> > have to make them reserved words anyway?
>
> Might as well. No point in writing
Out of interest, since the FE/BE protocol apprently doesn't support prepared
statements (bound variables), what does this patch actually _do_?
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Neil Conway
> Sent: Thursday, 11 April 2002 9:29 AM
On Wed, 10 Apr 2002, Bear Giles wrote:
> > In fact, my grammar currently has an obscene
> > 20 shift/reduce and 4 reduce/reduce conflicts!
>
> A shift/reduce conflict, IIRC, usually indicates a situation where
> the grammar is unambiguous but may be inefficient. Eliminating them
> is nice, but
> In fact, my grammar currently has an obscene
> 20 shift/reduce and 4 reduce/reduce conflicts!
A shift/reduce conflict, IIRC, usually indicates a situation where
the grammar is unambiguous but may be inefficient. Eliminating them
is nice, but not critical.
A R/R conflict, in contrast, is a poi
I don't see in this patch that you've added your new keywords to any of the
lists of reserved words towards the bottom of gram.y. Have a look down and
see the lists. You need to add the keywords to the first list in the file
that doesn't give a shift/reduce error. (ie. make the words the least
Gavin Sherry <[EMAIL PROTECTED]> writes:
>> NOTICE: RegisterSharedInvalid: SI buffer overflow
>> NOTICE: InvalidateSharedInvalid: cache state reset
> To fix this increase shared_buffers.
AFAIK shared_buffers has no direct effect on the rate of SI overruns.
I suppose it might have an indirect e
Neil Conway <[EMAIL PROTECTED]> writes:
> Unfortunately, bison isn't very
> helpful: it doesn't provide line-numbers when it warns me about
> the # of conflicts.
Run bison with -v switch (thus, "bison -y -d -v gram.y") and look at
the y.output file it produces. More detail than you really wanted
On Thu, 11 Apr 2002, Christopher Kings-Lynne wrote:
> Hi all,
>
> I got these odd messages while doing a vacuum in 7.1.3 0 - any idea what
> they mean? I assume it's not fatal as they're just notices, but I've never
> had them before and haven't had them since.
>
> NOTICE: RegisterSharedInvali
Hi all,
I got these odd messages while doing a vacuum in 7.1.3 0 - any idea what
they mean? I assume it's not fatal as they're just notices, but I've never
had them before and haven't had them since.
NOTICE: RegisterSharedInvalid: SI buffer overflow
NOTICE: InvalidateSharedInvalid: cache state
Hi all,
I'm working on a fairly large patch (cleaning up Karel Zak's
PREPARE/EXECUTE work), and I'm having some problems with bison (I'm
a yacc newbie). In fact, my grammar currently has an obscene
20 shift/reduce and 4 reduce/reduce conflicts!
Would someone to be kind enough to let me know what
Hiroshi Inoue wrote:
> > > Why ? As you already mentioned, there were not that many places
> > > to be changed.
> > >
> > > Well what's changed since then ?
> >
> > Here is an old email from me that outlines the idea of having a
> > physical/logical attribute numbering system, and the advantages.
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > Tom Lane wrote:
> >
> > > Hiroshi's "DROP_COLUMN_HACK" was essentially along this line, but
> > > I think he made a representational mistake by trying to change the
> > > attnums of dropped columns to be negative values.
> >
> > Negative attnums ha
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> That means that
> >> a lot of low-level places *do* need to know about the dropped-column
> >> convention, else they can't make any sense of tuple layouts.
>
> > Why ? As you already mentioned, there were not t
On Wed, 2002-04-10 at 21:55, Justin Clift wrote:
> Hannu Krosing wrote:
> >
> > On Wed, 2002-04-10 at 16:32, Justin Clift wrote:
> > > Hi everyone,
> > >
> > > This is Prof. Bayer's response to the question "is it alright to use
> > > UB-Tree's in Open Source projects?".
> >
> > Have you found o
Patents are as much designed to confuse and dissuade someone from using
something as they are to patent something. Reading a patent is often
harder than killing the nearest chicken, strewing it's entrails allover
the yard, and then trying to make some sense of it.
Justin Clift wrote:
>Hannu
Hello,
i searched around about privileges for functions, but it seems,
that there is nothing available in the 7.2.x series.
So my question: Is it possible to execute a function (in this case
a C function) with permissions of the function creater instead
of the user who's actual using function?
Awhile back I suggested adding a boolean column to pg_proc to control
which type coercion functions could be invoked implicitly, and which
would need an explicit cast:
http://archives.postgresql.org/pgsql-hackers/2001-11/msg00803.php
There is a relevant bug report #484 showing the dangers of too m
Justin Clift wrote:
> Hi everyone,
>
> I know we've already got a "rough" series of steps to follow when a new
> release comes out, but I feel it's worth putting out heads together and
> making a "cheat sheet" of which places to contact, and "known good"
> contacts there.
>
> Am thinking this af
Hiroshi Inoue wrote:
> Tom Lane wrote:
>
> > Hiroshi's "DROP_COLUMN_HACK" was essentially along this line, but
> > I think he made a representational mistake by trying to change the
> > attnums of dropped columns to be negative values.
>
> Negative attnums had 2 advantages then. It had a big
>
Hannu Krosing wrote:
>
> On Wed, 2002-04-10 at 16:32, Justin Clift wrote:
> > Hi everyone,
> >
> > This is Prof. Bayer's response to the question "is it alright to use
> > UB-Tree's in Open Source projects?".
>
> Have you found out _what_ exaclty is patented ?
>
> Is it just his concrete implem
On Wed, 2002-04-10 at 16:32, Justin Clift wrote:
> Hi everyone,
>
> This is Prof. Bayer's response to the question "is it alright to use
> UB-Tree's in Open Source projects?".
Have you found out _what_ exaclty is patented ?
Is it just his concrete implementation of "UB-Tree" or something
broade
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Also, Tom (or anyone): in regards to your previous email, should I just go
> back to using opt_symmetry to shorten the number of productions, since I
> have to make them reserved words anyway?
Might as well. No point in writing more product
Hi everyone,
This is Prof. Bayer's response to the question "is it alright to use
UB-Tree's in Open Source projects?".
It's a "No, but we can discuss a licensing model" type answer.
Regards and best wishes,
Justin Clift
Original Message
Subject: AW: More UB-Tree patent info
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> That means that
>> a lot of low-level places *do* need to know about the dropped-column
>> convention, else they can't make any sense of tuple layouts.
> Why ? As you already mentioned, there were not that many places
> to be changed.
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> I do have a concern about how to implement some of the SET commands if
> we *do* respect transactional semantics. For example, SET TIME ZONE
> saves the current value of an environment variable (if available), and
> would need *at least* a "before tran
Hi everyone,
I know we've already got a "rough" series of steps to follow when a new
release comes out, but I feel it's worth putting out heads together and
making a "cheat sheet" of which places to contact, and "known good"
contacts there.
Am thinking this after coming across the ZDNet download
Hiroshi Inoue wrote:
>
> Fernando Nasser wrote:
> >
> > As most things in the SQL standard, you have to collect information
> > from several places and add it together.
> >
> > Look at 4.20, 11.1 and specially at the rules for
> > .
> >
> > Then think a little bit about scenarios, trying to apply
Tom Lane wrote:
> Hiroshi's "DROP_COLUMN_HACK" was essentially along this line, but
> I think he made a representational mistake by trying to change the
> attnums of dropped columns to be negative values.
Negative attnums had 2 advantages then. It had a big
advantage that initdb isn't needed. N
Fernando Nasser wrote:
>
> As most things in the SQL standard, you have to collect information
> from several places and add it together.
>
> Look at 4.20, 11.1 and specially at the rules for
> .
>
> Then think a little bit about scenarios, trying to apply the rules.
>
> It is a pain, but there
58 matches
Mail list logo
