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
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
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
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, 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
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
seemed to me
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.
regards,
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 archived
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 limit.
I
[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:
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. A fully
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 more
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 across
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.
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 DATABASE x
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
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
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?
Even
[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:
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 -103
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 really
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
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 which
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 into
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
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
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 you sure
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 --help
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
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
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 scary and along
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 code
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
the automated
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,
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]
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.
* 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 /
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 developer
-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!.
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
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 access
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
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 at
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
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
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
separate
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 idea to
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 comfortable releasing?
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 - the
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
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:
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
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 searched
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.
Database do not
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
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
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 when
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
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
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.
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
61 matches
Mail list logo
