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 '
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 tape
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
> >> transactio
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 th
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 havin
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 ancien
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 individua
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 v
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
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
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) ?
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 this
Greg Sabino Mullane wrote:
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 conta
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 ORDER BY when displaying the view.
If someo
-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 St
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 liter
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 w
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 cou
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
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
> > h
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
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 n
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, etc.
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
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
o
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 c
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 broa
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
Title: Message
My
guess at a crude translation:
I am a young student at
the end of the cycle and I must make my term
project of the end
of the cycle on the topic of electronic management of a school database,
which must be done with PostgreSQL/php under Linux. I have assistance to instal
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 pro
Hi
i have a table 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 by one week whitout gaps between
them.
which will give the
following output:
1/1/2004 , 15/1/2004
29/1
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 tr
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 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
"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 everyth
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
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
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
(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
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 avec postgresql /php sous linux j'ai reussi à installer linux et postgresql dèja mais comment taper les codes postgrsql c'est a dire o
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
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 i
* 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
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?
100
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 u
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 wa
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 vi
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 mysql->
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 g
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 a
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 Meske
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.
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 jus
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
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 m
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
> >>> implementa
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 pa
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 g
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
On Thu, Jul 01, 2004 at 15:19:32 +0200,
Dennis Bjorklund <[EMAIL PROTECTED]> wrote:
>
> Looking again at the doc and the example I now know why it can't parse
> it. The example when simplified is:
>
> SELECT *
> FROM (select 1 ORDER BY 1
> UNION ALL
> select 2) AS x;
>
> and
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 si
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
>>> informatio
Dennis Bjorklund wrote:
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 wasn'
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 subtransacti
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:
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 () sho
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 cyc
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 upd
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 tha
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
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 u
> -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
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,
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 inform
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*, no
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
76 matches
Mail list logo
