On Thursday 22 February 2007 00:42, you wrote:
> I think you just made my point for me.
I wasn't trying to convince so much as get an opinion.
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 4: Have you searched our list archives?
On Thu, 22 Feb 2007, Warren Turkal wrote:
> On Thursday 22 February 2007 00:20, Tom Lane wrote:
> > Nobody got round to it. I believe it's listed in the TODO file ...
>
> It's not at [1]. Should someone add it to the TODO?
>
> [1]http://www.postgresql.org/docs/faqs.TODO.html
Yes it is.
"Allow i
Warren Turkal <[EMAIL PROTECTED]> writes:
> On Thursday 22 February 2007 00:05, Tom Lane wrote:
>> Not particularly. We keep hearing from various advocates that
>> $foo-is-better-than-CVS, but the preferred value of $foo changes with
>> amazing frequency, and none of the arguments seem to justify t
Warren Turkal <[EMAIL PROTECTED]> writes:
> On Thursday 22 February 2007 00:20, Tom Lane wrote:
>> Nobody got round to it. I believe it's listed in the TODO file ...
> It's not at [1]. Should someone add it to the TODO?
I see
* Dates and Times
o Allow infinite dates and intervals just l
On Thursday 22 February 2007 00:05, Tom Lane wrote:
> Not particularly. We keep hearing from various advocates that
> $foo-is-better-than-CVS, but the preferred value of $foo changes with
> amazing frequency, and none of the arguments seem to justify the pain
> of converting.
Some of the other op
On Thursday 22 February 2007 00:20, Tom Lane wrote:
> Nobody got round to it. I believe it's listed in the TODO file ...
It's not at [1]. Should someone add it to the TODO?
[1]http://www.postgresql.org/docs/faqs.TODO.html
wt
--
Warren Turkal (w00t)
---(end of broadcast
On Thu, 22 Feb 2007, Peter Eisentraut wrote:
Oleg Bartunov wrote:
It's not so big addition to the gram.y, see a list of commands
http://mira.sai.msu.su/~megera/pgsql/ftsdoc/sql-commands.html.
In that proposed syntax, I would drop all "=", ",", "(", and ")". They
don't seem necessary and they
Warren Turkal <[EMAIL PROTECTED]> writes:
> Is there a reason why the DATE type does not support infinity
Nobody got round to it. I believe it's listed in the TODO file ...
regards, tom lane
---(end of broadcast)---
TIP 1:
Joshua D. Drake wrote:
> This is like the third time we have been around this problem. The
> syntax is clear and reasonable imo.
But others have differing opinions.
> Can we stop arguing about it and just include? If there are specific
> issues beyond syntax that is one
> thing, but that this poi
Oleg Bartunov wrote:
> It's not so big addition to the gram.y, see a list of commands
> http://mira.sai.msu.su/~megera/pgsql/ftsdoc/sql-commands.html.
In that proposed syntax, I would drop all "=", ",", "(", and ")". They
don't seem necessary and they are untypical for SQL commands. I'd
compar
Warren Turkal <[EMAIL PROTECTED]> writes:
> Are there any plans to move to another SCMS in the future?
Not particularly. We keep hearing from various advocates that
$foo-is-better-than-CVS, but the preferred value of $foo changes with
amazing frequency, and none of the arguments seem to justify t
Is there a reason why the DATE type does not support infinity something like
the DATE type?
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> Right, I'm not advocating not doing that -- I'm just saying that the
>> first step to that could be decoupling physical position with attr id
>> :-) Logical column ordering (the order in which SELECT * expands to)
>> seems to me
On Monday 19 February 2007 22:59, Greg Smith wrote:
> I have a WIP patch that adds the main detail I have found I need to
> properly tune checkpoint and background writer activity. I think it's
> almost ready to submit (you can see the current patch against 8.2 at
> http://www.westnet.com/~gsmith/
Are there any plans to move to another SCMS in the future? I am curious, I
guess.
wt
--
Warren Turkal (w00t)
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
elein wrote:
The storage order is orthogonal to the display order. display order can be
handled
in attnum and the new storage order can be the new column.
If you review the earlier discussion you will see that it is proposed
(by Tom) to have 3 numbers (i.e. 2 new cols): an immutable id
On Wed, Feb 21, 2007 at 08:33:10PM +0100, Florian G. Pflug wrote:
> Simon Riggs wrote:
> >On Wed, 2007-02-21 at 09:25 -0500, Phil Currier wrote:
> >>On 2/21/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> >>>I'd expect the system being able to reoder the columns to the most
> >>>efficient order pos
On Thu, 22 Feb 2007, Gregory Stark wrote:
> "Gavin Sherry" <[EMAIL PROTECTED]> writes:
>
> > Can you elaborate on the 'two different sets of parameters' bit? I'm still
> > without coffee.
>
> The spec allows for arbitrarily complex recursive query structures. Including
> mutually recursive queries
"Gavin Sherry" <[EMAIL PROTECTED]> writes:
> Can you elaborate on the 'two different sets of parameters' bit? I'm still
> without coffee.
The spec allows for arbitrarily complex recursive query structures. Including
mutually recursive queries, and even non-linearly recursive queries. I found
grok
On Wed, 21 Feb 2007, Gregory Stark wrote:
> "Gavin Sherry" <[EMAIL PROTECTED]> writes:
>
> > The WITH support seems okay. I guess I'd thought it might be represented
> > different internally (not a sub query) but the approach Greg has taken is
> > probably more straight forward (in that you get a
Anyone making those kind of decisions probably wants a generic
"connection is encrypted" flag. It could be true if a GSSAPI
connection has negotiated use of a security layer.
Of course I don't have my GSSAPI patches working as well as the SASL
ones were yet, and I haven't started on adding
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>>
>>
>>> I would want to see this very carefully instrumented. Assuming we are
>>> putting
>>> all fixed size objects at the front, which seems like the best arrangement,
>>> th
Gregory Stark wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
I would want to see this very carefully instrumented. Assuming we are putting
all fixed size objects at the front, which seems like the best arrangement,
then the position of every fixed field and the fixed portion of the po
> Ron Mayer expressed the thought that we're complicating needlessly the
> UI for vacuum_delay, naptime, etc. He proposes that instead of having
> cost_delay etc, we have a mbytes_per_second parameter of some sort.
> This strikes me a good idea, but I think we could make that after this
> proposa
"Gavin Sherry" <[EMAIL PROTECTED]> writes:
> The WITH support seems okay. I guess I'd thought it might be represented
> different internally (not a sub query) but the approach Greg has taken is
> probably more straight forward (in that you get a lot of proven code for
> free). It should work fine
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> Greg Stark and Matthew O'Connor say that we're misdirected in having
> more than one worker per tablespace. I say we're not :-)
I did say that. But your comment about using a high cost_delay was fairly
convincing too. It would be a simpler design
Alvaro Herrera wrote:
Ok, scratch that :-) Another round of braindumping below.
I still think this is solution in search of a problem. The main problem
we have right now is that hot tables can be starved from vacuum. Most
of this proposal doesn't touch that. I would like to see that probl
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> I would want to see this very carefully instrumented. Assuming we are putting
> all fixed size objects at the front, which seems like the best arrangement,
> then the position of every fixed field and the fixed portion of the position
> of
> every va
Florian G. Pflug wrote:
BTW, this is a good case for why the storage order should - directly or
indirectly - be tweakable. You can either optimize for space, and _then_
for speed - which is what the OP did I think - or first for speed, and
then for space. If the dba cannot choose the strategy
On Feb 18, 9:35 am, [EMAIL PROTECTED] (Tom Lane) wrote:
> Russell Smith <[EMAIL PROTECTED]> writes:
>
> > If you replan and immutable function, aren't you possibly messing up a
> > functional index that is using the old function. Hey, if you change an
> > immutable function that has an index, you
Stephan Szabo wrote:
On Wed, 21 Feb 2007, Alvaro Herrera wrote:
Did I miss something in what you were trying to say? I assume you must
already know this.
I think so. What I was mentioning was that I was pretty sure that there
was a message with someone saying that they actually tried somethin
Stephan Szabo wrote:
What I was mentioning was that I was pretty sure that there
was a message with someone saying that they actually tried something that
did this and that they found left-most varchar access was slightly slower
after the reordering although general access was faster. I believ
Ok, scratch that :-) Another round of braindumping below.
Launcher starts one worker in each database. This worker is not going
to do vacuum work, just report how much vacuum effort is needed in the
database. "Vacuum effort" is measured as the total number of pages in
need of vacuum, being the
On Wed, 21 Feb 2007, Alvaro Herrera wrote:
> Stephan Szabo escribi?:
> > On Wed, 21 Feb 2007, Martijn van Oosterhout wrote:
> >
> > > On Wed, Feb 21, 2007 at 12:06:30PM -0500, Phil Currier wrote:
> > > > Well, for two reasons:
> > > >
> > > > 1) If you have a table with one very-frequently-accesse
Phil Currier escribió:
> On 2/21/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
> >So yes, there would be a use case for specifying the physical column layout
> >when pg_migrator is doing the pg_dump/restore. But pg_migrator could
> >probably
> >just update the physical column numbers itself. It's n
On 2/21/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
So yes, there would be a use case for specifying the physical column layout
when pg_migrator is doing the pg_dump/restore. But pg_migrator could probably
just update the physical column numbers itself. It's not like updating system
catalog tabl
On Wed, 21 Feb 2007, Jonah H. Harris wrote:
> As was discussed in several threads, I'd handed over the
> responsibility of hierarchical queries to Greg Stark several weeks
> ago. He posted a preliminary patch which I don't believe anyone
> looked at. For 8.3's sake, I wanted to make sure we get
Hello
yesterday I sent posted bug, bud it hangs because I am not member of
psql-bug mailing list. Can somebody look to queue?
Thank You
Pavel Stehule
_
Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/
-
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> As was discussed in several threads, I'd handed over the
> responsibility of hierarchical queries to Greg Stark several weeks
> ago. He posted a preliminary patch which I don't believe anyone
> looked at. For 8.3's sake, I wanted to make sure we ge
Alvaro Herrera wrote:
I haven't understood Alvaro to suggest not keeping 3 numbers.
Right, I'm not advocating not doing that -- I'm just saying that the
first step to that could be decoupling physical position with attr id
:-) Logical column ordering (the order in which SELECT * expands
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Why would a pg_migrator style upgrade use pg_dump at all? I assumed it
> would rather copy the verbatim data from the old to the new catalog,
> only changing it if the layout of the tables in pg_catalog actually changed.
The way pg_migrator works
Andrew Dunstan escribió:
> Simon Riggs wrote:
> >
> >I agree with comments here about the multiple orderings being a horrible
> >source of bugs, as well as lots of coding even to make it happen at all
> >http://archives.postgresql.org/pgsql-hackers/2006-12/msg00859.php
>
> I thought we were going
Stephan Szabo escribió:
> On Wed, 21 Feb 2007, Martijn van Oosterhout wrote:
>
> > On Wed, Feb 21, 2007 at 12:06:30PM -0500, Phil Currier wrote:
> > > Well, for two reasons:
> > >
> > > 1) If you have a table with one very-frequently-accessed varchar()
> > > column and several not-frequently-acces
Simon Riggs wrote:
I agree with comments here about the multiple orderings being a horrible
source of bugs, as well as lots of coding even to make it happen at all
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00859.php
I thought we were going with this later proposal of Tom's (o
Simon Riggs wrote:
On Wed, 2007-02-21 at 09:25 -0500, Phil Currier wrote:
On 2/21/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
I'd expect the system being able to reoder the columns to the most
efficient order possible (performance-wise and padding-saving-wise),
automatically. When you create
On Wed, 21 Feb 2007, Martijn van Oosterhout wrote:
> On Wed, Feb 21, 2007 at 12:06:30PM -0500, Phil Currier wrote:
> > Well, for two reasons:
> >
> > 1) If you have a table with one very-frequently-accessed varchar()
> > column and several not-frequently-accessed int columns, it might
> > actually
Phil Currier wrote:
On 2/21/07, Martijn van Oosterhout wrote:
> don't see any good way to perform an upgrade between PG versions
> without rewriting each table's data. Maybe most people aren't doing
> upgrades like this right now, but it seems like it will only become
> more common in the futu
On Thu, 2007-02-22 at 00:00 +0530, Pavan Deolasee wrote:
>
> On 2/21/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> I very much like Hannu's idea, but it does present some
> issues.
>
>
> I too liked Hannu's idea initially, but Tom raised a valid concern
> that i
On Wed, 2007-02-21 at 13:16 -0500, Andrew Dunstan wrote:
> Simon Riggs wrote:
> > On Wed, 2007-02-21 at 09:25 -0500, Phil Currier wrote:
> >
> >> On 2/21/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> >>
> >>> I'd expect the system being able to reoder the columns to the most
> >>> efficie
On 2/21/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
I very much like Hannu's idea, but it does present some issues.
I too liked Hannu's idea initially, but Tom raised a valid concern
that it does not address the basic issue of root tuples. According
to the idea, a DEAD root tuple can be used
Simon Riggs wrote:
On Wed, 2007-02-21 at 09:25 -0500, Phil Currier wrote:
On 2/21/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
I'd expect the system being able to reoder the columns to the most
efficient order possible (performance-wise and padding-saving-wise),
automatically. When yo
On 2/21/07, Martijn van Oosterhout wrote:
> don't see any good way to perform an upgrade between PG versions
> without rewriting each table's data. Maybe most people aren't doing
> upgrades like this right now, but it seems like it will only become
> more common in the future. In my opinion, t
On Mon, 2007-02-12 at 09:24 +0530, Pavan Deolasee wrote:
> On 2/12/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> Hannu Krosing wrote:
> > Ühel kenal päeval, P, 2007-02-11 kell 12:35, kirjutas Tom
> Lane:
> >> Hannu Krosing <[EMAIL PROTECTED]> writes:
>
On Wed, 2007-02-21 at 09:25 -0500, Phil Currier wrote:
> On 2/21/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > I'd expect the system being able to reoder the columns to the most
> > efficient order possible (performance-wise and padding-saving-wise),
> > automatically. When you create a table,
On Tue, 2007-02-20 at 09:48 +0200, Hannu Krosing wrote:
> I'm not sure about the "we are more concerned about the large tables"
> part. I see it more as a device for high-update tables. This may not
> always be the same as "large", so there should be some fallbacks for
> case where you can't get t
On Wed, Feb 21, 2007 at 12:06:30PM -0500, Phil Currier wrote:
> Well, for two reasons:
>
> 1) If you have a table with one very-frequently-accessed varchar()
> column and several not-frequently-accessed int columns, it might
> actually make sense to put the varchar column first. The system won't
Andrew Dunstan wrote:
Florian G. Pflug wrote:
I think you'd want to have a flag per field that tell you if the user
has overridden the storage pos for that specific field. Otherwise,
the next time you have to chance to optimize the ordering, you might
throw away changes that the admin has done
Martijn van Oosterhout wrote:
On Wed, Feb 21, 2007 at 03:59:12PM +0100, Florian G. Pflug wrote:
I think you'd want to have a flag per field that tell you if the user
has overridden the storage pos for that specific field. Otherwise,
the next time you have to chance to optimize the ordering, you
On 2/21/07, Martijn van Oosterhout wrote:
On Wed, Feb 21, 2007 at 03:59:12PM +0100, Florian G. Pflug wrote:
> I think you'd want to have a flag per field that tell you if the user
> has overridden the storage pos for that specific field. Otherwise,
> the next time you have to chance to optimize
On Friday 09 February 2007, Jan Wieck wrote:
> I am not sure, I would have to look at what exactly that hook provides.
> The key to a Lamport timestamp is that it is advancing it commit order
> (plus some other things ... of course). If the hook can guarantee that
> the calls are made always in com
Florian G. Pflug wrote:
I think you'd want to have a flag per field that tell you if the user
has overridden the storage pos for that specific field. Otherwise,
the next time you have to chance to optimize the ordering, you might
throw away changes that the admin has done on purpose. The same ho
Benjamin Arai wrote:
> Is there a way to give priorities to queries or users? Something similar to
> NICE in Linux. My goal is to give the updating (backend) application a very
> low priority and give the web application a high priority to avoid
> disturbing the user experience.
>
> Thanks in a
Jan Wieck wrote:
> On 1/25/2007 7:33 PM, Tom Lane wrote:
> >
> > 1 fires always
> > 0 fires never
> > N fires in "Normal" mode
> > R fires in "Replica" mode
> > other letters available for other future mode values?
> >
> > If you cons
On Wed, Feb 21, 2007 at 03:59:12PM +0100, Florian G. Pflug wrote:
> I think you'd want to have a flag per field that tell you if the user
> has overridden the storage pos for that specific field. Otherwise,
> the next time you have to chance to optimize the ordering, you might
> throw away changes
Alvaro Herrera wrote:
> Bruce Momjian escribi?:
> > Phil Currier wrote:
> > > On 2/21/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > > > I'd expect the system being able to reoder the columns to the most
> > > > efficient order possible (performance-wise and padding-saving-wise),
> > > > automat
Phil Currier wrote:
> On 2/21/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > Keep in mind we have a patch in process to reduce the varlena length and
> > reduce alignment requirements, so once that is in, reordering columns
> > will not be as important.
>
> Well, as I understand it, that patch i
On 2/21/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Keep in mind we have a patch in process to reduce the varlena length and
reduce alignment requirements, so once that is in, reordering columns
will not be as important.
Well, as I understand it, that patch isn't really addressing the same
pro
Bruce Momjian escribió:
> Phil Currier wrote:
> > On 2/21/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > > I'd expect the system being able to reoder the columns to the most
> > > efficient order possible (performance-wise and padding-saving-wise),
> > > automatically. When you create a table,
As was discussed in several threads, I'd handed over the
responsibility of hierarchical queries to Greg Stark several weeks
ago. He posted a preliminary patch which I don't believe anyone
looked at. For 8.3's sake, I wanted to make sure we get the status of
this out on the table so there won't b
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Markus Schiltknecht wrote:
>>> Are there any ongoing efforts to rewrite the parser (i.e. using
>>> another algorithm, like a recursive descent parser)?
>> Why would you want to do that?
> Last, but not least, the C and C++ syntax is basically set
Alvaro Herrera wrote:
Florian G. Pflug wrote:
However, I just realized that doing this is much harder than I initially
thought, because catalog access always happens with SnapshotNow, and
e.g. "drop table" deletes datafiles at commit time, and not during vacuum.
Not to mention the likenesses
Phil Currier wrote:
On 2/21/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
I'd expect the system being able to reoder the columns to the most
efficient order possible (performance-wise and padding-saving-wise),
automatically. When you create a table, sort the columns to the most
efficient order;
Markus Schiltknecht wrote:
Are there any ongoing efforts to rewrite the parser (i.e. using
another algorithm, like a recursive descent parser)?
Why would you want to do that?
I recall having read something about rewriting the parser. Together with
Tom being worried about parser performance an
Phil Currier wrote:
> On 2/21/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > I'd expect the system being able to reoder the columns to the most
> > efficient order possible (performance-wise and padding-saving-wise),
> > automatically. When you create a table, sort the columns to the most
> > e
Markus Schiltknecht wrote:
Hi,
I recall having read something about rewriting the parser. Together
with Tom being worried about parser performance and knowing GCC has
switched to a hand written parser some time ago, I suspected bison to
be slow. That's why I've asked.
This has little to do
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Markus Schiltknecht wrote:
>> I didn't find hard facts about runtime complexity of LALR,
>> though (pointers are very welcome).
> a) and b) should be O(1). Processing one token pushes at most one state
> onto the stack, so overall no more than N st
Nikolay Samokhvalov wrote:
> Also, in the future more "non-libxml" functionality could be added to
> "XML support" (well, Peter's recent SQL-to-XML mapping functions
> prove it).
But note that those are not controlled by the --with-libxml switch.
--
Peter Eisentraut
http://developer.postgresql.o
Hi,
Florian G. Pflug wrote:
According to http://en.wikipedia.org/wiki/LR_parser processing one
token in any LR(1) parser in the worst case needs to
a) Do a lookup in the action table with the current (state, token) pair
b) Do a lookup in the goto table with a (state, rule) pair.
c) Push one s
On 2/21/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
I'd expect the system being able to reoder the columns to the most
efficient order possible (performance-wise and padding-saving-wise),
automatically. When you create a table, sort the columns to the most
efficient order; ALTER TABLE ADD COLU
Florian G. Pflug wrote:
> However, I just realized that doing this is much harder than I initially
> thought, because catalog access always happens with SnapshotNow, and
> e.g. "drop table" deletes datafiles at commit time, and not during vacuum.
Not to mention the likenesses of CLUSTER and TRUNC
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Oleg Bartunov wrote:
> >> It's not so big addition to the gram.y, see a list of commands
> >> http://mira.sai.msu.su/~megera/pgsql/ftsdoc/sql-commands.html.
>
> > I looked at the diff file and the major change in gram.y is the creatio
Nikolay Samokhvalov wrote:
> Now we have --with-libxml (and USE_LIBXML constant for #ifdef-s), what
> is not absolutely right: XML support is smth that is more general than
> "using libxml2 library". E.g., some SQL/XML publishing functions (such
> as XMLPI) do not deal with libxml2.
>
> Also, in t
Theo Schlossnagle wrote:
On Feb 20, 2007, at 1:40 PM, Tom Lane wrote:
RPK <[EMAIL PROTECTED]> writes:
I did not mean asking for undo from a life-time log. Since FlashBack
Technology is already there, I just mean that world's most advanced
database
(PostgreSQL, as they say), must have an opt
Phil Currier escribió:
> Inspired by this thread [1], and in particular by the idea of storing
> three numbers (permanent ID, on-disk storage position, display
> position) for each column, I spent a little time messing around with a
> prototype implementation of column storage positions to see what
Markus Schiltknecht wrote:
Hi,
Tom Lane wrote:
You mean four different object types. I'm not totally clear on bison's
scaling behavior relative to the number of productions
You really want to trade parser performance (which is *very*
implementation specific) for ease of use?
Bison generat
Hi there,
We have several patches already discussed in -hackers and waiting for
decision. Current versions adapted for HEAD are available:
1. built-in FTS http://www.sigaev.ru/misc/tsearch_core-0.35.gz
Documentation is available http://mira.sai.msu.su/~megera/pgsql/ftsdoc/
as a separate book,
On Mon, Feb 19, 2007 at 11:18:36AM -0500, Tom Lane wrote:
>
> Magnus, I'd suggest reverting whatever you did to your MSVC script,
> so we'll find out the next time someone makes this mistake...
>
Reverted. I left the part in genbki.pl in there, because that's a plain
bug that was exposed by this
Hi,
Tom Lane wrote:
You mean four different object types. I'm not totally clear on bison's
scaling behavior relative to the number of productions
You really want to trade parser performance (which is *very*
implementation specific) for ease of use?
Bison generates a LALR [1] parser, which
> Do 97% of transactions commit because Oracle has slow rollbacks and
> developers are working around that performance issue, or because they
> really commit?
>
> I have watched several developers that would prefer to issue numerous
> selects to verify things like foreign keys in the applica
No.
I think one option is "fix it in the cvs client". There
are options there to do it if you use cvsnt.
FWIW, if I built off the snapshot tarballs things work, since they have
unix linefeeds.
//Magnus
On Tue, Feb 20, 2007 at 05:11:41PM -0500, Bruce Momjian wrote:
>
> Was this problem addresse
90 matches
Mail list logo
