David Wheeler <[EMAIL PROTECTED]> writes:
> On Mar 31, 2006, at 16:01, Tom Lane wrote:
>> It seems rather pointless to document two instances of what is in fact
>> a generic autoconf-script behavior ...
> I'm sorry to be such a moron about this, but what exactly is that
> behavior? That you can
Neil Conway <[EMAIL PROTECTED]> writes:
> i.e. the LISTEN/NOTIFY argument is not the name of a relation, so it
> wouldn't make much sense to schema-qualify it.
I'm not entirely sure why we even have the grammar allowing qualified
names in these statements. It's not documented that you can do that
On Fri, 2006-03-31 at 20:27 -0500, Agent M wrote:
> Why is the schema ignored entirely when using listen/notify?
Per the docs:
Commonly, the notification name is the same as the name of some
table in the database, and the notify event essentially means, "I
changed this table, take a l
On 3/31/06, Martijn van Oosterhout wrote:
> On Fri, Mar 31, 2006 at 03:02:47PM -0600, Tony Caduto wrote:
> > Has there ever been any talk of adding a first aggregate function?
> > It would make porting from Oracle and Access much easier.
> >
> > Or is there something in the contrib modules that I
On Fri, Mar 31, 2006 at 06:52:51PM -0500, Tom Lane wrote:
> David Wheeler <[EMAIL PROTECTED]> writes:
> > But that's a PITA. I'd much rather have been able to tell configure
> > *which* perl to use:
>
> >./configure --with-perl=/usr/bin/perl5.8.6
>
> The more usual way to handle this sort o
Why is the schema ignored entirely when using listen/notify? I couldn't
find any mention of this in the documentation.
Ideally, it should support schemas (and store any string it takes) but
it should at least throw an error when a schema is prepended. I guess
the workaround is to simply delete
On Mar 31, 2006, at 16:01, Tom Lane wrote:
It seems rather pointless to document two instances of what is in fact
a generic autoconf-script behavior ...
I'm sorry to be such a moron about this, but what exactly is that
behavior? That you can specify an environment variable for whatever *
i
On Mar 31, 2006, at 15:52, Tom Lane wrote:
The more usual way to handle this sort of thing is to put each version
of perl in a different directory, and then you can alter PATH while
running configure to pick which one you want. I've got several
versions
of perl on this machine that I select
David Wheeler <[EMAIL PROTECTED]> writes:
> Yes, but even the environment variables get me what I want. I
> therefore respectfully submit the attached patch to document them in
> the INSTALL file.
It seems rather pointless to document two instances of what is in fact
a generic autoconf-script
David Wheeler <[EMAIL PROTECTED]> writes:
> But that's a PITA. I'd much rather have been able to tell configure
> *which* perl to use:
>./configure --with-perl=/usr/bin/perl5.8.6
The more usual way to handle this sort of thing is to put each version
of perl in a different directory, and the
On Mar 31, 2006, at 12:40, Josh Berkus wrote:
In support of David's suggestion, I'll point out that most other OSS
software configuration scripts (Apache, PHP, etc.) I deal with
supports
the above syntax.
Yes, but even the environment variables get me what I want. I
therefore respectfully
On Fri, Mar 31, 2006 at 03:02:47PM -0600, Tony Caduto wrote:
> Has there ever been any talk of adding a first aggregate function?
> It would make porting from Oracle and Access much easier.
>
> Or is there something in the contrib modules that I might have missed?
There are several oracle compata
Has there ever been any talk of adding a first aggregate function?
It would make porting from Oracle and Access much easier.
Or is there something in the contrib modules that I might have missed?
Thanks,
--
Tony Caduto
AM Software Design
http://www.amsoftwaredesign.com
Home of PG Lightning Admi
People:
>./configure --with-perl=/usr/bin/perl5.8.6
In support of David's suggestion, I'll point out that most other OSS
software configuration scripts (Apache, PHP, etc.) I deal with supports
the above syntax.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---
On Mar 31, 2006, at 12:05, Seneca Cunningham wrote:
Like passing PERL=/usr/bin/perl5.8.6 to configure?
Is that currently supported? Because, if so, it's documented AFAICT.
Best,
David
---(end of broadcast)---
TIP 5: don't forget to increase yo
David Wheeler wrote:
But that's a PITA. I'd much rather have been able to tell configure
*which* perl to use:
./configure --with-perl=/usr/bin/perl5.8.6
Would it be possible to add support for an optional argument to the PL/*
options (--with-perl,--with-python, --with-tcl) so that we can ge
Dear PostgreSQL Hackers,
I recently ran into an issue where I was having trouble compiling
PostgreSQL with PL/Perl. Although Mac OS X 10.4 comes with a dynamic
Perl, I long ago compiled my own Perl, which is static. So /usr/bin/
perl was my static Perl, and /usr/bin/perl5.8.6 is the stock Pe
I wrote:
> I'm thinking we should change the code and the README to specify that
> you must mark the buffer dirty before you can END_CRIT_SECTION().
While looking at this I realized that in fact we need to, and do,
mark the buffer dirty even earlier than that: look at bufmgr.c
LockBuffer and SyncO
On 3/31/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> This argument falls flat when you consider that the width of a CHAR
> entry is measured in characters, not bytes, and therefore its physical
> size is not fixed even if its logical width is.
Gotta love multibyte :)
--
Jonah H. Harris, Database Int
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> On Wed, 29 Mar 2006, Tom Lane wrote:
>> That loses the ability to reflect tuple deadness back into LP_DELETE
>> flags, no?
> At first glance, it doesn't look so hard. index_getmulti could mark
> those tids that are dead, and btgetmulti would rescan
On Fri, 2006-03-31 at 09:36 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Problem for indexes only. heap xlrecs don't specify exact insert points
>
> Sure they do. They had better, else (for example) the associated index
> insertions will be wrong.
Yep, you're right.
Best
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> About the only reason I use CHAR in other databases systems is when I
> know that the field will always contain the same amount of data, ie:
> storing a SHA1. In these cases it's silly to have a 4 byte overhead to
> store length. I really wish CHAR in Po
On Fri, 31 Mar 2006 09:35:31 -0600
"Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 30, 2006 at 10:15:21AM -0500, D'Arcy J.M. Cain wrote:
> > I had to do multi-master replication for a major project and we wound
> > up writing our own replication system. The problem is that this sort of
> >
On Fri, Mar 31, 2006 at 10:45:15AM -0500, Jonah H. Harris wrote:
> On 3/31/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > What are you using a char[64] for anyway? You should probably consider
> > using NameData, if you want to store an identifier.
>
> It's just a fixed length string that will
On 3/31/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> What are you using a char[64] for anyway? You should probably consider
> using NameData, if you want to store an identifier.
It's just a fixed length string that will never change in size and as
such, I'd like not to add the overhead of any
Jonah H. Harris wrote:
> On 3/31/06, Qingqing Zhou <[EMAIL PROTECTED]> wrote:
> > What if you put your char[64] before relhassubclass, then you
> > don't change CLASS_TUPLE_SIZE.
>
> Thought about that... but it would be an ugly place for this column.
> I know I could get around it by renumbering
On 3/31/06, Qingqing Zhou <[EMAIL PROTECTED]> wrote:
> What if you put your char[64] before relhassubclass, then you
> don't change CLASS_TUPLE_SIZE.
Thought about that... but it would be an ugly place for this column.
I know I could get around it by renumbering the attribute, but that's
just a k
On Thu, Mar 30, 2006 at 10:15:21AM -0500, D'Arcy J.M. Cain wrote:
> I had to do multi-master replication for a major project and we wound
> up writing our own replication system. The problem is that this sort of
> thing really has to be based on your own business rules. There is no
> way to make
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> It may be not good but not harmful either. On step2, the transaction will
> abort and leave a page that has been changed but not marked dirty. There are
> two situtations could happen after that. One is step 3, the other is the
> page is still in the bu
Simon Riggs <[EMAIL PROTECTED]> writes:
> Problem for indexes only. heap xlrecs don't specify exact insert points
Sure they do. They had better, else (for example) the associated index
insertions will be wrong.
> Accesses to local buffers don't need to be critical sections either.
True, but in
On Thu, 2006-03-30 at 13:51 -0500, Tom Lane wrote:
> This is pretty much what heapam and btree currently do, but on looking
> at it I think it's got a problem: we really ought to mark the buffer
> dirty before releasing the critical section. Otherwise, if there's an
> elog(ERROR) before the Write
""Jonah H. Harris"" <[EMAIL PROTECTED]> wrote
>
> Yeah, I noticed that one. How would you suggest setting
> CLASS_TUPLE_SIZE in that case?
>
What if you put your char[64] before relhassubclass, then you don't change
CLASS_TUPLE_SIZE.
Regards,
Qingqing
---(end of broad
"Tom Lane" <[EMAIL PROTECTED]> wrote
>
> This is pretty much what heapam and btree currently do, but on looking
> at it I think it's got a problem: we really ought to mark the buffer
> dirty before releasing the critical section. Otherwise, if there's an
> elog(ERROR) before the WriteBuffer call
33 matches
Mail list logo
