John DeSoi <[EMAIL PROTECTED]> writes:
> No hard feelings about it, but I'm really surprised existing behavior
> will be broken when the technical reasons for changing it were so weak.
We've only had domains for one release cycle, so it seems to me that
there's not a lot of track record to justi
On Thursday, June 26, 2003, at 11:22 PM, Tom Lane wrote:
By my count you're in the minority --- there was no one lobbying
for reporting domain OIDs in the previous threads, and at least
two people strongly in favor of not doing so. While I don't have
a strong opinion about it myself, I don't have
On Fri, Jun 27, 2003 at 10:45:46AM +1000, Philip Yarra wrote:
> ECPGget_connection, both of which share a mutex. Would it be okay if we did
> the following:
> ...
As you know I have never tried using threads, so feel free to go ahead
and change this. Either commit to cvs ot send me a patch.
Mich
John DeSoi <[EMAIL PROTECTED]> writes:
> My vote would be to restore the previous behavior and add
> connection-specific setting for clients that need it.
By my count you're in the minority --- there was no one lobbying
for reporting domain OIDs in the previous threads, and at least
two people st
On Thu, 26 Jun 2003, Bruce Momjian wrote:
>
> See my recent commit of src/tools/pgtest. It might be a good start.
Yes this is a good start. This is a little concerning though:
pg_ctl stop
rm -rf "$PGDATA"
Perhaps a warning is warranted (ie, $PGDATA shouldn't point to your
production data clus
Tom Lane wrote:
Weiping He <[EMAIL PROTECTED]> writes:
because the data type (UUID) is a struct,
and the uuid_eq() function accept two pointer to the value of struct uuid,
if make it IMMUTABLE, postgresql would think it should not try to run
the function, but return the cached value instead whe
> As people who are needing to move away from Oracle due to cost
> restrictions, I wanted to know how much work, or what the status is of
> this option. Please respond asap if possible. I have to give my VP info
> on this relatively soon.
A lot of work is needed, and I wouldnt' even guarantee it
> ROTFL... the answer is no. Feature freeze is Tuesday, people. In
> practice, the time to start coding new stuff is already long past.
> Especially major new stuff.
>
> If you start now you might have something done for 7.5.
Can everyone who is interested in actually coding a tablespaces
implem
> > Tablespaces
> > databases
> >schemas
> > objects
> >
> > with each of them implemented as a directory and data files under it. If
we
> > could get a quota check propogated in both direction, that would be
pretty
> > good, may be a warning when things start getting close to limit.
Dat
> Good question.
>
> If it gets in 7.4, that would be more than a killer feature to put against
7.4
> release, with due respect to all other enhancements in progress..
It's not going to happen.
Chris
---(end of broadcast)---
TIP 6: Have you search
Rod Taylor <[EMAIL PROTECTED]> writes:
> I've not tried, but if PostgreSQL can do an 'out of tree' compile it
> could make it much easier.
Yes it can, following the usual procedure for autoconfiscated trees:
just invoke configure from an empty directory, eg
mkdir build
cd build
On Fri, 27 Jun 2003 12:16 pm, Bruce Momjian wrote:
> BSD/OS supports:
>
> The pthreads library conforms to IEEE Std1003.1c
> (``POSIX'').
>
> How is that different from UNIX98?
Just checked up on this: apparently version "g" of the standard does contain
such manipulation functions...
See my recent commit of src/tools/pgtest. It might be a good start.
---
Gavin Sherry wrote:
> On Thu, 26 Jun 2003, Kevin Brown wrote:
>
> > The Hermit Hacker wrote:
> > > On Wed, 25 Jun 2003, Kevin Brown wrote:
> > >
> >
BSD/OS supports:
The pthreads library conforms to IEEE Std1003.1c
(``POSIX'').
How is that different from UNIX98?
---
Philip Yarra wrote:
> On Fri, 27 Jun 2003 11:58 am, AgentM wrote:
> > According to POSIX
On Fri, 27 Jun 2003 11:58 am, AgentM wrote:
> According to POSIX 1003.1c-1995, no such mutex-altering function exists.
Thanks for the info - useful to know.
> lock the mutex- potentially again). Either that or the recursive locks
> can be eliminated.
Avoiding recursive locks is my preference - t
On Thu, 26 Jun 2003, Kevin Brown wrote:
> The Hermit Hacker wrote:
> > On Wed, 25 Jun 2003, Kevin Brown wrote:
> >
> > > So...would it make sense to create a gborg project to which people who
> > > have written their own test suites can contribute whatever code and data
> > > they feel comfortabl
On Thu, 26 Jun 2003, Kevin Brown wrote:
> > It doesn't sound like a bad idea ... but, it pretty much comes down to the
> > original thread: are you willing to step up and maintain such a project?
>
> Yes, I am ("how hard can it be?", he asks himself, knowing all the
> while that it's a really bad
The Hermit Hacker wrote:
> On Wed, 25 Jun 2003, Kevin Brown wrote:
>
> > So...would it make sense to create a gborg project to which people who
> > have written their own test suites can contribute whatever code and data
> > they feel comfortable releasing? As a gborg project, it would be
> > sep
According to POSIX 1003.1c-1995, no such mutex-altering function exists.
pthread_mutexattr_get/settype(...) functions are defined by X/Open XSH5
(Unix98). I would suggest writing a wrapper for OSs that don't
implement recursive locks (it's easy enough to make your own
implementation- just chec
The Hermit Hacker wrote:
On Thu, 26 Jun 2003, Thomas Swan wrote:
Of course, these are just ideas and I'm not sure how practical it is to
do any of them. I just am really concerned about the uninstall/clean up
phase and how that can be done in an orderly fashion. Unless the
process can start
On Thu, 26 Jun 2003, Rod Taylor wrote:
> I think we should replace Bruce's pgtest script with this one -- with an
> argument to accept the email address to report to for FAILING cases.
> Success isn't very interesting if it runs regularly.
that was why I suggested getting it into the tree ... to
On Thu, 26 Jun 2003, Thomas Swan wrote:
> Of course, these are just ideas and I'm not sure how practical it is to
> do any of them. I just am really concerned about the uninstall/clean up
> phase and how that can be done in an orderly fashion. Unless the
> process can start from a clean state ag
On Thu, 26 Jun 2003 11:19 am, Philip Yarra wrote:
> there appears to still be a problem
> occurring at "EXEC SQL DISCONNECT con_name". I'll look into it tonight if I
> can.
I did some more poking around last night, and believe I have found the issue:
RedHat Linux 7.3 (the only distro I have acce
-Original Message-
From: Rod Taylor [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 26, 2003 3:33 PM
To: Gonyou, Austin
Cc: Thomas Swan; Nigel J. Andrews; Tom Lane; PostgreSQL Development
Subject: RE: Two weeks to feature freeze
On Thu, 2003-06-26 at 16:09, Gonyou, Austin wrote:
> DOH!.
On Thu, 2003-06-26 at 16:09, Gonyou, Austin wrote:
> DOH!. YesYou're right I totally forgot about that. My apologies. I
> believe though, that there is a HP testing lab that is somewhat like OSDL,
> in that they offer OSS free services and many platforms to run on. (used to
> be compaq's develo
> * clean the source, destination directories
> * pull latest CVS tip down.
Why tip? Lets simply update the current source tree to the most current
of whatever branch they had checked out initially.
Running it on older stable branches is just as useful.
> * record environment / inst
DOH!. YesYou're right I totally forgot about that. My apologies. I
believe though, that there is a HP testing lab that is somewhat like OSDL,
in that they offer OSS free services and many platforms to run on. (used to
be compaq's developer testdrive sort of program) I believe it still exists.
On Thu, 2003-06-26 at 15:00, Austin Gonyou wrote:
> I know I'm new to this list, but is OSDL's testing capabilities out of
> the question?
From what I've seen, OSDL is only concerned with a very very small set
of platforms (Linux in a couple of configurations).
--
Rod Taylor <[EMAIL PROTECTED]>
Or if you want this behaviour all the time, one call of
setvbuf(mypipe,(char *)0,_IONBF,0);
should do the trick (much easier than remebering to have to call fflush()
all the time).
If not using streams, and just calling write(), then you probably don't have
to worry.
andrew
BTW, "system('slee
> Assuming you're using file streams to write to the pipe, fflush() will do
> the trick.
The problem is that the pipe (from \o |tee ) is intermingling writes
to stdout by tee with direct writes to stdout from within psql.
I do issue a fflush, because that's necessary to make the pipe do its
I know I'm new to this list, but is OSDL's testing capabilities out of
the question?
On Thu, 2003-06-26 at 13:48, Thomas Swan wrote:
> Nigel J. Andrews wrote:
>
> >On Thu, 26 Jun 2003, Thomas Swan wrote:
> >
> >
> >>Is it possible the sourceforge compile farms could be used for some of
> >>th
Assuming you're using file streams to write to the pipe, fflush() will do
the trick.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> [EMAIL PROTECTED]
> Sent: Thursday, June 26, 2003 2:20 PM
> To: pgsql hackers list
> Subject: [HACKERS] A portable cod
Nigel J. Andrews wrote:
>On Thu, 26 Jun 2003, Thomas Swan wrote:
>
>
>>Is it possible the sourceforge compile farms could be used for some of
>>the automated testing? I'm not sure how that system works, but it could
>>be worth looking into.
>>
>>
>
>Isn't the sourceforge license very scar
In the little fix I came up with for psql last night, I need to be able
to ensure that something sent to a pipe (and then to stdout) completes
before issuing the prompt directly to stdout.
I did this with: "system ('sleep 1');", but I'm fairly sure that is
not portable nor does it ENSURE compl
Paul Ramsey <[EMAIL PROTECTED]> writes:
> Entirely sure:
Hmph. There must be some bug in the 7.3 code for it then. Since we've
already ripped out that code for 7.4, I'm not too excited about finding
the problem...
regards, tom lane
---(end of bro
Entirely sure:
[EMAIL PROTECTED] pg_dump]$ which pg_dump
/opt/pgsql73/bin/pg_dump
[EMAIL PROTECTED] pg_dump]$ pg_dump -t "*" pramsey
--
-- PostgreSQL database dump
--
[EMAIL PROTECTED] pg_dump]$
Tom Lane wrote:
Paul Ramsey <[EMAIL PROTECTED]> writes:
Oh, if it's by design then the "pg_dump --hel
Paul Ramsey <[EMAIL PROTECTED]> writes:
> Oh, if it's by design then the "pg_dump --help" text should be updated
> correspondingly. The online doco is already correct.
Hm. Wait a minute --- I was thinking of 7.4 not 7.3. The "*" hack does
appear to still be there in the 7.3 source code. Are yo
> Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> > On Thursday 26 June 2003 21:56, [EMAIL PROTECTED] wrote:
> >> Is this doable within the time frame for the 7.4 feature freeze?
>
> > Good question.
>
> ROTFL... the answer is no. Feature freeze is Tuesday, people. In
> practice, the time to
Tom,
Thanks for helping me find the previous discussion.
2) Better support for domains. Currently the jdbc driver is broken
with
regards to domains (although no one has reported this yet). The driver
will treat a datatype that is a domain as an unknown/unsupported
datatype. It would be great
Fernando,
> We have a server side GUI utility that among other things let us configure
GUC
> variables. We badly need to know what variables exist in the specific
backend
> version, which are the min and max values and if possible a description.
The
> option is to hardwire these things int
Oh, if it's by design then the "pg_dump --help" text should be updated
correspondingly. The online doco is already correct.
Tom Lane wrote:
Paul Ramsey <[EMAIL PROTECTED]> writes:
We are trying to do an "all tables" dump using the 7.3.3 pg_dump, but
are getting no love. The pg_dump command whi
Hi Peter,
We have a server side GUI utility that among other things let us configure GUC
variables. We badly need to know what variables exist in the specific backend
version, which are the min and max values and if possible a description. The
option is to hardwire these things into the code
I seem to recall that Table partitioning used to be on the *urgent*
heading of the ToDo list. Now I see it is under misc.
As people who are needing to move away from Oracle due to cost
restrictions, I wanted to know how much work, or what the status is of
this option. Please respond asap if possi
On Thu, 26 Jun 2003, Thomas Swan wrote:
> >
> Is it possible the sourceforge compile farms could be used for some of
> the automated testing? I'm not sure how that system works, but it could
> be worth looking into.
Isn't the sourceforge license very scary and along the lines of "whatever you
Lee Kindness wrote:
Guys, surely some one's done this before? I've tried using
PQescapeBytea too, but still get (slightly) different output. If I try
and insert "\x02\x01\x02\x03\x04hello\x05\x64\x99\x45" I get (int
values of chars printed):
INSERT: 2 1 2 3 4 104 101 108 108 111 5 100 -10
Thomas Swan <[EMAIL PROTECTED]> writes:
> Is it possible the sourceforge compile farms could be used for some of
> the automated testing? I'm not sure how that system works, but it could
> be worth looking into.
The last time I used it (which admittedly was a year or two back), they
didn't real
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> On Thursday 26 June 2003 21:56, [EMAIL PROTECTED] wrote:
>> Is this doable within the time frame for the 7.4 feature freeze?
> Good question.
ROTFL... the answer is no. Feature freeze is Tuesday, people. In
practice, the time to start coding ne
[EMAIL PROTECTED] writes:
> Being able to zap a database with one or more 'rm -rf' commands assumes
> that there will be files from just ONE database permitted in any given
> tablespace, and ONLY files from that database.
I said no such thing. Look at the structure again:
$PGDATA/base/dboid/..
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Thomas Swan writes:
Have you considered something similar to the Mozilla tinderbox approach
where you have a daemon checkout the cvs, compile, run regression tests,
and report a status or be able to report a status?
Eve
Guys, surely some one's done this before? I've tried using
PQescapeBytea too, but still get (slightly) different output. If I try
and insert "\x02\x01\x02\x03\x04hello\x05\x64\x99\x45" I get (int
values of chars printed):
INSERT: 2 1 2 3 4 104 101 108 108 111 5 100 -103 69
SELECT: 2 1
On Thursday 26 June 2003 21:56, [EMAIL PROTECTED] wrote:
> Is this doable within the time frame for the 7.4 feature freeze?
Good question.
If it gets in 7.4, that would be more than a killer feature to put against 7.4
release, with due respect to all other enhancements in progress..
Shridhar
> > Well, with above proposal, drop database should be as simple. It's just that
> > it would be more than one `rm -rf`rather than just one.
>
> Right, there would be potentially one per tablespace. The key point
> here is that the tablespace definitions are known cluster-wide, so a
> "DROP DATA
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> On Thursday 26 June 2003 21:29, Tom Lane wrote:
>> I can see no reason that we'd want a level of directory associated with
>> schemas...
> Moving a multi-hundreds-of-GB table across schemas would be sooo easy..:-)
No, it would be harder.
On Thursday 26 June 2003 21:29, Tom Lane wrote:
> Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> > Well, consider this. Keep in mind that all of them are directories..
>
> I can see no reason that we'd want a level of directory associated with
> schemas...
Moving a multi-hundreds-of-GB table a
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> Well, consider this. Keep in mind that all of them are directories..
I can see no reason that we'd want a level of directory associated with
schemas...
> Well, with above proposal, drop database should be as simple. It's just that
> it would be m
On Thursday 26 June 2003 20:22, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > I disagree. Just as you can have multiple schemas within one database
> > you can have multiple tablespaces within one database.
> >
> > And the tablespace is irrelevant as far as specifying an object is
> > concerned.
[EMAIL PROTECTED] writes:
> I disagree. Just as you can have multiple schemas within one database
> you can have multiple tablespaces within one database.
> And the tablespace is irrelevant as far as specifying an object is concerned.
> A fully qualified object would be:
> database.schema.
> That should be
>
> Tablespaces
> databases
>schemas
> objects
>
> with each of them implemented as a directory and data files under it. If we
> could get a quota check propogated in both direction, that would be pretty
> good, may be a warning when things start getting close to lim
John DeSoi <[EMAIL PROTECTED]> writes:
> On Wednesday, June 25, 2003, at 10:42 PM, Tom Lane wrote:
>> No, 7.4 intentional change. If you want to argue that this was a bad
>> idea, it's not too late ... but see the archived discussions about it.
> Can you give me a pointer on where to find the arc
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Is this deliberate?
> usa=# select '1-1--2001'::date;
> [works]
The guys who might actually be able to tell you whether it was an
intended behavior are long gone. But I don't see any particular
problem with it.
regar
Tom Lane once said:
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> >> Andrew Overholt of Red Hat has been working
> >> on this, but is certainly not going to make the Tuesday feature-freeze
> >> deadline.
>
> > I was just wondering who was working on it and what the progress was...? It
On Wednesday, June 25, 2003, at 10:42 PM, Tom Lane wrote:
No, 7.4 intentional change. If you want to argue that this was a bad
idea, it's not too late ... but see the archived discussions about it.
Hi Tom,
Can you give me a pointer on where to find the archived discussions? I
have tried all
I don't see a tag for in cvs for the 7.3.3 release.
Kris Jurka
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
On Wednesday 25 June 2003 20:49, [EMAIL PROTECTED] wrote:
> > Well, correct solution is to implement tablespaces on which objects like
> > databases, tables and indexes can be put.
>
> I've not looked at the SQL standard, but it seems to me like the order
> should be:
>
> Databases
>Tablespaces
Is this deliberate?
usa=# select '1-1-2001'::date;
date
2001-01-01
(1 row)
usa=# select '1-1--2001'::date;
date
2001-01-01
(1 row)
usa=# select '1-1---2001'::date;
date
2001-01-01
(1 row)
usa=# select '1--1--2001'
> This is irrelevant to what I'm doing, in any case, and it's not an itch
> I feel personally. Work on it yourself if you want it ...
OK, I figured it out. :-)
It's a fairly short patch in 7.3.3, what do I need to do to submit it
for 7.4?
I also made a minor functional change that may need to
66 matches
Mail list logo
