On Thu, 1 Jul 2004, Justin Clift wrote:
but we found it useful. It adds the column comments to the
information_schema.columns view.
Doesn't the specification say exactly what columns should exist?
Lots of things in the old system tables are not visible in the
information_schema because of
On Thu, Jul 01, 2004 at 12:21:55AM -0400, Tom Lane wrote:
I was all set to launch into a diatribe about the half dozen performance
issues I think we *must* fix in the new nested-transactions code,
I completely agree, of course.
This brought me up short. I sure as heck do not see anything in
Hi Tom,
As requested - although the results are all over the place... :-(
One interesting factor in these tests is that the max tps without
the new code was 74.7, with the new code, 85.8.
This is a Sony Laptop, slow IDE disk, Fedora Core 2
[EMAIL PROTECTED] pgsql-HEAD]$ uname -a
Linux
hi
,
I am on a mission to simply keep a starving project off the ground by updating an old
mysql-pgsql perl conversion script which does its conversion very differently from
the one under contrib/. There is an old link to
http://www.rot13.org/~dpavlin/sql.html
on techdocs under the section
Not sure how worthwhile others will find this small patch (to CVS HEAD),
but we found it useful. It adds the column comments to the
information_schema.columns view.
Is column comment in the standard? If not, we cannot of course add it...
Chris
---(end of
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
In file included from /usr/include/python2.3/Python.h:8,
from plpython.c:58:
/usr/include/python2.3/pyconfig.h:847:1: warning: _POSIX_C_SOURCE
redefined
In file included from /usr/include/stdio.h:28,
from
Joe Conway [EMAIL PROTECTED] writes:
In addition to the ecpg warnings mentioned by Tom, I'm also seeing
compile warnings wrt plpython:
make[3]: Entering directory `/opt/src/pgsql-cvs/pgsql-7.5/src/pl/plpython'
gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes
Tom Lane wrote:
Justin Clift [EMAIL PROTECTED] writes:
Not sure how worthwhile others will find this small patch (to CVS HEAD),
but we found it useful. It adds the column comments to the
information_schema.columns view.
This question has been touched on before, but I guess it's time to face
it
Justin Clift [EMAIL PROTECTED] writes:
Not sure how worthwhile others will find this small patch (to CVS HEAD),
but we found it useful. It adds the column comments to the
information_schema.columns view.
This question has been touched on before, but I guess it's time to face
it fair and
This question has been touched on before, but I guess it's time to face
it fair and square: is it reasonable for an SQL implementation to add
implementation-specific columns to an information_schema view? One
could certainly argue that the entire point of information_schema is
to be *standard*,
Justin Clift wrote:
Tom Lane wrote:
This question has been touched on before, but I guess it's time to face
it fair and square: is it reasonable for an SQL implementation to add
implementation-specific columns to an information_schema view? One
could certainly argue that the entire point of
On Thu, Jul 01, 2004 at 12:21:55AM -0400, Tom Lane wrote:
This brought me up short. I sure as heck do not see anything in that
patch that would represent a performance gain over before, especially
not in the very vanilla-flavor cases exercised by pgbench. Do you see
an explanation?
Oh,
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: 01 July 2004 05:33
To: Justin Clift
Cc: PostgreSQL Hackers Mailing List
Subject: Re: [HACKERS] Adding column comment to
information_schema.columns
Justin Clift [EMAIL
Hi guys,
Not sure if this is a known issue or not, but I think I may have found a
bug with the way view definitions are shown... at least in psql.
Using 7.5 development CVS (as of a few hours ago) or even 7.4.3, if I
connect using it's version of psql to a database (of the same version),
then
On Thu, 1 Jul 2004, Justin Clift wrote:
Not sure if this is a known issue or not, but I think I may have found a
bug with the way view definitions are shown... at least in psql.
Using 7.5 development CVS (as of a few hours ago) or even 7.4.3, if I
connect using it's version of psql to a
Christopher Browne [EMAIL PROTECTED] writes:
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Jaime Casanova) would
write:
Can anyone tell me if postgresql has problems with xeon processors?
If so, there is any fix or project of fix it?
Well, there's a known issue that IA-32
Alvaro Herrera [EMAIL PROTECTED] writes:
Oh, also the inval.c code now is saving a lot of pfrees at each
transaction end.
Nope, that's not it; the old code actually did no retail pfree's
anyway --- I just diked out what was really dead code.
Besides which, pgbench doesn't do any catalog
On Thu, Jul 01, 2004 at 08:51:59AM -0400, Tom Lane wrote:
The only thing that's occurred to me since last night is that I
simplified the data structures in trigger.c enough to get rid of
a separate memory context for them. That means one less
MemoryContextCreate/Delete per transaction cycle.
On Thu, 1 Jul 2004, Dennis Bjorklund wrote:
\d information_schema.constraint_column_usage
The thing that does not work is that the SELECT to the left of the UNION
ALL needs to be put inside (), then it works and the parser can parse it.
Looking at the doc page it looks like the () should
On Thu, Jul 01, 2004 at 09:07:11AM -0400, Alvaro Herrera wrote:
Were your numbers also taken with --enable-cassert? It might be
instructive to compare numbers taken without.
Ah, yes, it was with asserts enabled. I'll try again.
With asserts disabled the situations seems reverted:
Alvaro Herrera [EMAIL PROTECTED] writes:
Well, my opinion is that cursors and other resources should at least be
usable from a inner subtransaction in its parent -- because if that
can't be done we are wasting some of the benefits, because we can't just
stick everything in a subtransaction to
Dennis Bjorklund wrote:
snip
I've still not checked any code. I don't even know what part of pg it is
that produce that bad SQL. The view itself works, so it must be the pretty
printer that is broken (where ever that is hidden away in the code).
Thanks Dennis.
So, it's definitely a bug then. I
Andreas Pflug [EMAIL PROTECTED] writes:
Justin Clift wrote:
Tom Lane wrote:
This question has been touched on before, but I guess it's time to
face it fair and square: is it reasonable for an SQL
implementation to add implementation-specific columns to an
information_schema view? One
On Thu, 1 Jul 2004, Bruno Wolff III wrote:
If DISTINCT ON or LIMIT was used in inner select, then the ORDER BY would
be relevant; so you can't just blindly remove ORDER BY when it is part of
a union.
Of course, but in this case with this view there wasn't any such. It can
still be usable
Dennis Bjorklund [EMAIL PROTECTED] writes:
On Thu, 1 Jul 2004 [EMAIL PROTECTED] wrote:
There is a huge difference between adhering to a standard and limiting
yourself to a standard.
Having pg specific system tables (as we do) is something we need of
course, for things that are not in the
On Thu, Jul 01, 2004 at 10:38:02 -0600,
[EMAIL PROTECTED] wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Yes, but if folks wanted to stick to the standard PostgreSQL would
still work. The only difference is that people who aren't concerned
about being more tied to PostgreSQL would get
Dennis Bjorklund [EMAIL PROTECTED] writes:
The view itself works, so it must be the pretty
printer that is broken (where ever that is hidden away in the code).
Yeah, I think this is due to overenthusiastic removal of parentheses.
I believe if you pg_dump the view you will get a correctly
On Thu, 1 Jul 2004 [EMAIL PROTECTED] wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Justin Clift wrote:
Tom Lane wrote:
This question has been touched on before, but I guess it's time to
face it fair and square: is it reasonable for an SQL
implementation to add
Christopher Browne wrote:
The fix for this problem is to rewrite all of your applications so
that they become conscious of which bits of memory they're using so
they can tune their own behaviour. This, of course, requires
discarding useful notions such as virtual memory that are _assumed_
by most
On Thu, 1 Jul 2004 [EMAIL PROTECTED] wrote:
We're advertising to do pure ANSI, so we'd mislead people if we
supplied non-standard columns.
Yes, but if folks wanted to stick to the standard PostgreSQL would
still work. The only difference is that people who aren't concerned
about being
Okay folks, it's July 1, and the long-threatened feature freeze for 7.5
is now in place. That means future patches that introduce new features
will be held off till the next development cycle. Bug fixes, cleanup
of loose ends, and (ahem) documentation are of course still welcome.
Since we've
Tom Lane wrote:
Okay folks, it's July 1, and the long-threatened feature freeze for 7.5
is now in place. That means future patches that introduce new features
will be held off till the next development cycle. Bug fixes, cleanup
of loose ends, and (ahem) documentation are of course still welcome.
On Wed, Jun 30, 2004 at 10:05:35PM -0400, Tom Lane wrote:
I'm seeing this:
...
Sorry, I simply did not see this. Fix just committed.
Looks like that last patch needs a bit o' work yet ...
As I said it needs some bug fixing. Albeit I expected more severe bugs.
:-)
Michael
--
Michael Meskes
Is there going to be an option to abort the complete transaction without
knowing how deep you are? Perhaps something like ABORT ALL.
The reason I suggest this, is that I can foresee an application or user
leaving nested transactions open inadvertently, or not knowing how
deeply nested they
Sorry for the delay, life tends to get complicated if you leave it
alone for a few days...
I see how making PREPARE obey rollbacks would be inconvenient for some
existing code, but frankly I'm getting a bit worried about the why should
I care whether what I do is committed or not? argument. I
I don't see the old link you are referring to (and neither did grep); is
this on the main page of techdocs or someplace else?
Robert Treat
On Thu, 2004-07-01 at 01:02, joseph speigle wrote:
hi
,
I am on a mission to simply keep a starving project off the ground by updating an
old
Dennis Bjorklund [EMAIL PROTECTED] writes:
On Thu, 1 Jul 2004, Bruno Wolff III wrote:
If DISTINCT ON or LIMIT was used in inner select, then the ORDER BY would
be relevant; so you can't just blindly remove ORDER BY when it is part of
a union.
Of course, but in this case with this view there
Jeroen wrote:
I see how making PREPARE obey rollbacks would be inconvenient for some
existing code, but frankly I'm getting a bit worried about the why
should
I care whether what I do is committed or not? argument. I guess one
could
say that about lots of statements: I don't really want this
Hi all,
I'm a young developer with some knowledge in various programming languages including C. Nowadays, i'm not capable to contribute to any part of the postgresql project but i want seriously learn what i need in order to contribute.
Can you guys tell me where can i start?
Where can i find
Hi All -
We are reviewing possible database and operating systems solutions for our
company and we are looking at running PostgreSQL on Linux.
Does PostgreSQL have the capability to handle the following requirements?
Is anyone successfully running an application with similar characteristics?
* jacob koehler (RRes-Roth) [EMAIL PROTECTED] [2004-06-27 20:58]:
cons:
- its not standard SQL (uses oracle style syntax)
Besides the GPL issue, this is my biggest problem.
i am aware of the fact that tom lane pointed to the fact that Andrew
Overholt did work towards SQL99 compliant
Survey: Motivation of Free/Open Source Software (F/OSS) Developers
We (Marc Röttig and Carl-Daniel Hailfinger) are currently working
on a survey on the motivation of open source developers as part of
a Computer Science and Society project at the CS department of the
University of Tübingen. We
Now that PG will have tablespaces I can stick my really high I/O data on a
fiberchannel array, and save some money by putting the rest of it (also the
majority of it) on less expensive SCSI RAID sets. Will I also be able to
tune individual tablespaces with the likes of random_page_cost? Sorry if
je suis un jeune étudiant en fin de cycle et je dois faire mon memoire de fin de cyclesur le thème suivant gestion electronique d'une ecole la base doit se faire avecpostgresql /php sous linux j'ai reussi à installer linux et postgresql dèjamais comment taper les codes postgrsql c'est a dire où
(sorry I have to post it again in plain text)
I'm currently working on a master student research project ¡°support
triggers on columns¡± that is supervised by a professor from my university
(Ottawa U). I have contacted Neil Conway whose name is with this item on
the TODO list. It happened that he
I'm currently working on a master student research project support triggers on
columns that is supervised by a professor from my university (Ottawa U).
I have contacted Neil Conway whose name is with this item on the TODO list. It
happened that he actually lives very close to me(Queen's U
On Thu, 1 Jul 2004 12:23:10 -0500, Bruno Wolff III [EMAIL PROTECTED] wrote:
Is there any provision in the information schema part of the standard for
vendor specific extensions?
Yes, there is:
An SQL-implementation may define objects that are associated with
INFORMATION_SCHEMA that
On Thu, Jul 01, 2004 at 04:06:06PM -0400, Merlin Moncure wrote:
The big picture here is that with the current behavior, it is possible
to keep track of existence of prepared statements without wrapping or
even being aware of transaction activity. This is tremendously useful
for handling
Matthew T. O'Connor [EMAIL PROTECTED] writes:
Tom Lane wrote:
Okay folks, it's July 1, and the long-threatened feature freeze for 7.5
is now in place.
What about features that have been submitting patches and trying to get
included for a few weeks now.
I already said that everything now in
On Mon, Jun 28, 2004 at 10:50:53PM +0200, Marc R?ttig wrote:
Survey: Motivation of Free/Open Source Software (F/OSS) Developers
Some remarks:
- Although the MIME header doesn't say it, the document is encoded in a
Windows-specific encoding. This is screwing up the apostrophes (')!
- Q3
ok, i'll fix some nasty bugs, and post it here for review.
regards,
evgen
-Original Message-
On Tue, Jun 29, 2004 at 07:23:45PM +0800, Christopher Kings-Lynne wrote:
I'm a PostgreSQL developer and I would like to see an SQL99 recursive
queries feature in PostgreSQL.
Me too, on bot
On Thu, Jul 01, 2004 at 02:01:37PM -0500, Thomas Swan wrote:
Is there going to be an option to abort the complete transaction without
knowing how deep you are? Perhaps something like ABORT ALL.
The reason I suggest this, is that I can foresee an application or user
leaving nested
Hi
i have atable of dates let's
say:
1/1/2004
8/1/2004
15/1/2004
29/1/2004
5/2/2004
12/2/2004
I am searching for a way to have the minimum date
and maximum date for dates seperated byone week whitout gaps between
them.
which will give the
followingoutput:
1/1/2004, 15/1/2004
29/1/2004
On Wed, Jun 30, 2004 at 10:56:53PM -0400, Joseph Shraibman wrote:
Seeing how small storage for a number type is compared to a text type,
and seeing how they tend to be queried on a lot, shouldn't it be
reasonable for the default stats number for numerics to be 100 instead
of 10?
The
Title: Message
My
guess at a crude translation:
I am a young student at
the end of the cycle and I must make myterm
project ofthe end
ofthe cycle on the topicof electronic management of a schooldatabase,
whichmust be done with PostgreSQL/php under Linux.I haveassistance to install Linux
Hi Mike,
In this release, unfortunately not.
I had some idea early on of putting rand_page_cost in pg_tablespace and
having the planner have access to it for costing. I didn't actually get
around to it but. :-(
Gavin
On Mon, 28 Jun 2004, Mike Rylander wrote:
Now that PG will have tablespaces
Jochem van Dieten wrote:
PS I think I spotted an inconsistency in the standard. It says to
tables that are defined in this Clause, while the Clause only
defines views, not tables.
Tables are base tables, views are derived tables, so this is OK.
---(end of
On Thu, 1 Jul 2004, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Well, my opinion is that cursors and other resources should at least be
usable from a inner subtransaction in its parent -- because if that
can't be done we are wasting some of the benefits, because we can't
Alvaro Herrera wrote:
On Wed, Jun 30, 2004 at 10:56:53PM -0400, Joseph Shraibman wrote:
Seeing how small storage for a number type is compared to a text type,
and seeing how they tend to be queried on a lot, shouldn't it be
reasonable for the default stats number for numerics to be 100 instead
On Thu, 2004-07-01 at 18:38 -0400, Alvaro Herrera wrote:
On Thu, Jul 01, 2004 at 02:01:37PM -0500, Thomas Swan wrote:
Is there going to be an option to abort the complete transaction without
knowing how deep you are? Perhaps something like ABORT ALL.
The reason I suggest this, is that
Yes, I know it's not possible, but can anyone suggest an alternative for
this problem?
I've written a very simple trigger-driven replication system, which
works in stages. First the trigger generates an entry in a log table
which is a fully formatted sql command... insert into/delete from,
Jeroen T. Vermeulen wrote:
If it's that important, come up with a generic session-not-transaction
syntax to temporarily escape bracketing.
Do you have a proposal for this? It seems to me that if your argument is
that if you want the old behaviour, you could add this extension means
that you need
On Thursday 01 July 2004 01:10 pm, Jaime Casanova wrote:
I'm a young developer with some knowledge in various programming
languages including C. Nowadays, i'm not capable to contribute to any
part of the postgresql project but i want seriously learn what i need in
order to contribute. Can you
On Thu, 1 Jul 2004, Mike Rylander wrote:
On Thursday 01 July 2004 06:43 pm, Gavin Sherry wrote:
Hi Mike,
In this release, unfortunately not.
That't too bad, but it's not that urgent I suppose.
I had some idea early on of putting rand_page_cost in pg_tablespace and
having the
On Thu, 2004-07-01 at 18:54, Gavin Sherry wrote:
On Thu, 1 Jul 2004, Mike Rylander wrote:
On Thursday 01 July 2004 06:43 pm, Gavin Sherry wrote:
Hi Mike,
In this release, unfortunately not.
That't too bad, but it's not that urgent I suppose.
I had some idea early on of
There is a huge difference between adhering to a standard and limiting
yourself to a standard. The real question is whether PostgreSQL's
goal is to support SQL standards, or whether PostgreSQL's goal is to
give PostgreSQL users a useful set of tools.
There are literally _hundreds_ of fields we
On Thu, Jul 01, 2004 at 04:47:09PM -0700, Mike Benoit wrote:
On Thu, 2004-07-01 at 18:38 -0400, Alvaro Herrera wrote:
On Thu, Jul 01, 2004 at 02:01:37PM -0500, Thomas Swan wrote:
If we change the syntax, say by using SUBCOMMIT/SUBABORT for
subtransactions, then using a simple ABORT would
Christopher Kings-Lynne wrote:
There is a huge difference between adhering to a standard and limiting
yourself to a standard. The real question is whether PostgreSQL's
goal is to support SQL standards, or whether PostgreSQL's goal is to
give PostgreSQL users a useful set of tools.
There are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I agree. The stuff is certainly accessible in PG-specific tables, so
the argument that we are missing functionality doesn't hold any water
IMHO. The question is whether we have to keep information_schema
pristine. I think that you and
Tom Lane wrote:
snip
Actually, if you look at the source code (information_schema.sql) there
is no ORDER BY in it, only a DISTINCT. The ORDER BY gets added by the
parser to help implement the DISTINCT. Sooner or later we should look
at suppressing the added ORDER BY when displaying the view.
If
Greg Sabino Mullane wrote:
snip
If there is that much clamor for this, why not make a new schema,
such as pginformation_schema People could then tweak the views
to their heart's content, while keeping 100% compliance.
Doesn't sound very neat.
If we add a pginformation_schema, then it'd probably
gmake[3]: Entering directory `/space/1/home/chriskl/pgsql/src/pl/plperl'
gcc -O2 -fno-strict-aliasing -g -fpic -DPIC -I.
-I/usr/libdata/perl/5.00503/mach/CORE -I../../../src/include -c -o
SPI.o SPI.c -MMD
SPI.xs: In function `XS__spi_exec_query':
SPI.xs:51: `aTHX_' undeclared (first use in
It's not a data corrupting bug but it's stopping view definitions from
working as advertised which is bad if you're used to being able to
rely on them. :-/
Hmm, is this wrong on line 2085 of src/backend/adt/utils/ruleutils.c:
need_paren = (PRETTY_PAREN(context) ?
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Hmm, is this wrong on line 2085 of src/backend/adt/utils/ruleutils.c:
need_paren = (PRETTY_PAREN(context) ?
!IsA(op-rarg, RangeTblRef) : true);
In a quick glance this code seems close to completely brain dead
Justin Clift [EMAIL PROTECTED] writes:
Tom Lane wrote:
Actually, if you look at the source code (information_schema.sql) there
is no ORDER BY in it, only a DISTINCT. The ORDER BY gets added by the
parser to help implement the DISTINCT. Sooner or later we should look
at suppressing the added
Christopher Kings-Lynne wrote:
gmake[3]: Entering directory `/space/1/home/chriskl/pgsql/src/pl/plperl'
gcc -O2 -fno-strict-aliasing -g -fpic -DPIC -I.
-I/usr/libdata/perl/5.00503/mach/CORE -I../../../src/include -c -o
SPI.o SPI.c -MMD
I am going to bet dollars to donuts that it is your perl
In a quick glance this code seems close to completely brain dead :-(
For one thing, why isn't it making separate determinations about whether
the left and right inputs of the UNION (resp INTERSECT or EXCEPT)
operator need to be parenthesized? After that maybe we could figure out
what the
gmake[3]: Entering directory `/space/1/home/chriskl/pgsql/src/pl/plperl'
gcc -O2 -fno-strict-aliasing -g -fpic -DPIC -I.
-I/usr/libdata/perl/5.00503/mach/CORE -I../../../src/include -c -o
SPI.o SPI.c -MMD
I am going to bet dollars to donuts that it is your perl version. Perl
5.00503 is
Mike Benoit [EMAIL PROTECTED] writes:
On Thu, 2004-07-01 at 18:38 -0400, Alvaro Herrera wrote:
If we change the syntax, say by using SUBCOMMIT/SUBABORT for
subtransactions, then using a simple ABORT would abort the whole
transaction tree.
But then we're back to the application having to know
On Fri, 2 Jul 2004, Christopher Kings-Lynne wrote:
gmake[3]: Entering directory `/space/1/home/chriskl/pgsql/src/pl/plperl'
gcc -O2 -fno-strict-aliasing -g -fpic -DPIC -I.
-I/usr/libdata/perl/5.00503/mach/CORE -I../../../src/include -c -o
SPI.o SPI.c -MMD
I am going to bet dollars to donuts
On Thu, 2004-07-01 at 22:14, Tom Lane wrote:
Mike Benoit [EMAIL PROTECTED] writes:
On Thu, 2004-07-01 at 18:38 -0400, Alvaro Herrera wrote:
If we change the syntax, say by using SUBCOMMIT/SUBABORT for
subtransactions, then using a simple ABORT would abort the whole
transaction tree.
bonjour,
si je vous comprends ce que vous demandez est comment utiliser la programme psql.
En bref, c'est une programme laquelle on utilise afin de parler avec la base. puis
que vous aviez deja fait l'installation, il devra suffir de taper psql at the
command line et vous serez pret a taper
Marc G. Fournier wrote:
On Fri, 2 Jul 2004, Christopher Kings-Lynne wrote:
I am going to bet dollars to donuts that it is your perl version.
Perl 5.00503 is ancient. Try upgrading to at least 5.6.
Not much I can do about that - it's builtin as part of FreeBSD 4.x
series.
And I bet its still the
83 matches
Mail list logo
