On Tue, 2009-09-08 at 16:07 -0400, Alvaro Herrera wrote:
> Tom Lane wrote:
> > Michael Gould writes:
> > > It would be nice if we could enable and disable column and table
> > > constraints. I believe that you can do this in Oracle but this is very
> > > handy for testing stored procedures and ot
> pgbench has #defines for number of branches, tellers, and accounts. There
> are used to populate the tables with -i, but when running actual benchmark
> it has values separately hard-coded in the query metacommands. This patch
> makes the metacommands obtain their values from the relevant #defi
> > In my understanding src/interfaces/ecpg/preproc/parser.c linkes to
> > src/backend/parser/parser.c. So they are identical, no?
>
> They haven't been identical since 8.2.
It seems my working files for ecpg are confused. Removing symlink and
cvs update fixed my problem. Thanks.
--
Tatsuo Ishii
I wrote:
> David Fetter writes:
>> WITH RECURSIVE t(j) AS (
>> WITH RECURSIVE s(i) AS (
>> VALUES (1)
>> UNION ALL
>> SELECT i+1 FROM s WHERE i < 10
>> ) SELECT i AS j FROM s
>> UNION ALL
>> SELECT j+1 FROM t WHERE j < 10
>> )
>> SELECT * FROM t;
>> ERROR: relation
Tatsuo Ishii writes:
> In my understanding src/interfaces/ecpg/preproc/parser.c linkes to
> src/backend/parser/parser.c. So they are identical, no?
They haven't been identical since 8.2.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
> No, it doesn't ... but maybe you've somehow overwritten
> src/interfaces/ecpg/preproc/parser.c with src/backend/parser/parser.c ?
In my understanding src/interfaces/ecpg/preproc/parser.c linkes to
src/backend/parser/parser.c. So they are identical, no?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
--
Se
Tatsuo Ishii writes:
> Has anybody seen this? It seems ecpg tries to link with backend functions.
No, it doesn't ... but maybe you've somehow overwritten
src/interfaces/ecpg/preproc/parser.c with src/backend/parser/parser.c ?
regards, tom lane
--
Sent via pgsql-hackers
On Sep 8, 2009, at 5:33 PM, Itagaki Takahiro wrote:
WHEN clause in other times [1][2][3]. (All of them use "WHEN" for the
syntax; that's why I proposed "WHEN" but not "WHERE".)
Well, looks like WHEN is, or is going to be standard:
::=
[ FOREACH { ROW | STATEMENT } ]
[ WHEN ]
(page 653
Hi,
Has anybody seen this? It seems ecpg tries to link with backend functions.
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels
-fno-strict-aliasing -DECPG_COMPILE -L../../../../src/port
-Wl,-rpath,'/usr/local/src/pgsql/current/lib' preproc.o type.o ecpg.o output.o
parser.o
On Tue, Sep 8, 2009 at 6:29 PM, Andrew
Gierth wrote:
>> "David" == David Fetter writes:
>
> >> I've attempted to search the archives for references to the SQL
> >> LATERAL feature, which AIUI is fairly-frequently requested.
> >> [snip]
> >> Has anyone poked at this at all?
>
> David> I be
"Kevin Grittner" wrote:
> How much does that buy you versus including this at the start of
> trigger_func:
One of the benefits is that it could handle tuple modifications
by another trigger, that is discussed here:
http://archives.postgresql.org/pgsql-hackers/2009-09/msg00161.php
| 2. Reche
Alvaro Herrera wrote:
> This INCLUDING STORAGE is supposed to copy reloptions?
No. It copies only storage parameters of columns to control TOAST policy.
It might be good to have some features to copy reloptions with convenient
way, but it will be done in another patch.
> to me it sounds like i
On Sep 8, 2009, at 4:18 PM, Tom Lane wrote:
Robert Creager writes:
I'll set up one or two more 'machines' if there is interest (Snow
Leopard)
LLVM, perhaps, though are you sure that llvm and gcc aren't the
same thing under the hood on SL? I thought I'd read somewhere that
Apple had turned
> "David" == David Fetter writes:
>> I've attempted to search the archives for references to the SQL
>> LATERAL feature, which AIUI is fairly-frequently requested.
>> [snip]
>> Has anyone poked at this at all?
David> I believe Andrew (RhodiumToad) Gierth is taking a look at
David> impl
Robert Creager writes:
> I'll set up one or two more 'machines' if there is interest (Snow
> Leopard)
LLVM, perhaps, though are you sure that llvm and gcc aren't the
same thing under the hood on SL? I thought I'd read somewhere that
Apple had turned gcc into a wrapper around the llvm code gen
On Tue, Sep 08, 2009 at 03:29:29PM -0600, Robert Creager wrote:
>
> I'll set up one or two more 'machines' if there is interest (Snow
> Leopard)
The more, the merrier :)
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfet
On Sep 7, 2009, at 6:10 PM, Tom Lane wrote:
Alvaro Herrera writes:
Pavel Stehule escribió:
Isn't better to solve the the correct diagnostics for INSTEAD
rules or triggers?
As far as I can tell it's not possible to do better without
letting the
user put their hands on the tag.
And how i
David Fetter writes:
> WITH RECURSIVE t(j) AS (
> WITH RECURSIVE s(i) AS (
> VALUES (1)
> UNION ALL
> SELECT i+1 FROM s WHERE i < 10
> ) SELECT i AS j FROM s
> UNION ALL
> SELECT j+1 FROM t WHERE j < 10
> )
> SELECT * FROM t;
> ERROR: relation "s" does not exist
>
I'll set up one or two more 'machines' if there is interest (Snow
Leopard)
% /Developer/usr/bin/llvm-gcc-4.2 --version
i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc.
build 5646) (LLVM build 2118)
llvm-gcc-4.2 currently fails during check for the known directory
probl
On Mon, Sep 7, 2009 at 6:53 AM, Itagaki
Takahiro wrote:
>
> Peter Eisentraut wrote:
>
>> Therefore, it cannot be completely unexpected if column triggers are
>> called even if the column was not actually changed in a semantically
>> significant way.
>
> Ok, the attached patch implements standard-c
On Sep 8, 2009, at 7:38 AM, Kevin Grittner wrote:
David Fetter wrote:
CREATE TRIGGER trig BEFORE UPDATE ON tbl FOR EACH ROW
WHEN (NEW.col IS DISTINCT FROM OLD.col)
EXECUTE PROCEDURE trigger_func();
How much does that buy you versus including this at the start of
trigger_func:
On
Folks,
I tried the following and it broke:
WITH RECURSIVE t(j) AS (
WITH RECURSIVE s(i) AS (
VALUES (1)
UNION ALL
SELECT i+1 FROM s WHERE i < 10
) SELECT i AS j FROM s
UNION ALL
SELECT j+1 FROM t WHERE j < 10
)
SELECT * FROM t;
ERROR: relation "s" does not exist
L
Tom Lane wrote:
> Michael Gould writes:
> > It would be nice if we could enable and disable column and table
> > constraints. I believe that you can do this in Oracle but this is very
> > handy for testing stored procedures and other external processes.
>
> Drop the constraint and re-add it late
Michael Gould writes:
> It would be nice if we could enable and disable column and table
> constraints. I believe that you can do this in Oracle but this is very
> handy for testing stored procedures and other external processes.
Drop the constraint and re-add it later...
On Tue, Sep 8, 2009 at 2:06 PM, Ron Mayer wrote:
> Andrew Dunstan wrote:
>> In any case, I don't accept this analogy. The mechanics of a Linux
>> distribution are very different from the mechanics of a project like
>> PostgreSQL. The prominent OSS project that seems to me most like ours is
>> the A
Ups, my previous patch was already applied in HEAD. This patch
removes
the sed-patch and added the check and set of ARCHFLAGS.
This seems to be assuming a lot more about the behavior of Apple's
Perl
hacks than I think we should. The patch as committed is good, because
having any -arch flag
Jan Otto writes:
> Ups, my previous patch was already applied in HEAD. This patch removes
> the sed-patch and added the check and set of ARCHFLAGS.
This seems to be assuming a lot more about the behavior of Apple's Perl
hacks than I think we should. The patch as committed is good, because
havi
Josh Berkus wrote:
> I can't find information about HTTPD release planning so I'll take your
> word for it. On the other hand, I have to point out that Apache is
> releasing HTTPD major versions an average of once every 3 years. I
> don't think we want to go to 3 years, do we?
I'd say it depends
Ups, my previous patch was already applied in HEAD. This patch removes
the sed-patch
and added the check and set of ARCHFLAGS.
diff -c -r1.655 configure
*** configure 8 Sep 2009 18:15:55 - 1.655
--- configure 8 Sep 2009 18:30:04 -
***
*** 6941,6949
{ $as_ec
Given the desire to defer pinning the type of a literal, for better
support of user defined types, I think the current semantics of all
the conditional expressions:
http://www.postgresql.org/docs/8.4/interactive/functions-conditional.html
are somewhat broken.
As a quick sample of something wh
Andrew Dunstan wrote:
> In any case, I don't accept this analogy. The mechanics of a Linux
> distribution are very different from the mechanics of a project like
> PostgreSQL. The prominent OSS project that seems to me most like ours is
> the Apache HTTP project.
I'd think that File Systems might
> In any case, I don't accept this analogy. The mechanics of a Linux
> distribution are very different from the mechanics of a project like
> PostgreSQL. The prominent OSS project that seems to me most like ours is
> the Apache HTTP project. But they don't do timed releases AFAIK, and
> theirs is
The problem here is that ARCHFLAGS is not set. If it is set correctly
the ldopts would be correctly set:
$ export ARCHFLAGS="-arch x86_64"
$ perl -MExtUtils::Embed -e ldopts
-arch x86_64 -L/usr/local/lib -L/System/Library/Perl/5.10.0/darwin-
thread-multi-2level/CORE -lperl -ldl -lm -lutil -lc
hi tom,
perl_embed_ldflags is currently the difference of
perl -MExtUtils::Embed -e ldopts
minus
perl -MConfig -e 'print $Config{ccdlflags}'
In that spirit, the answer would be to find something else in
ExtUtils
or Config that we can remove from ldopts.
As far as I can tell, there is nothin
On Tue, Sep 08, 2009 at 12:12:10PM -0400, Alvaro Herrera wrote:
> Hi,
>
> I'm seeking more powerful "any" pseudotypes. In particular,
> consider a function
>
> foo(type1, type2) returns type3
>
> where type1 and type2 can be both any element type, but not
> necessarily both of the same type. C
"David E. Wheeler" writes:
> On Sep 8, 2009, at 9:25 AM, Tom Lane wrote:
>> If you don't want any constraints at all on the argument types, you
>> can use "any" (with the quotes, because it's a reserved word :-().
> Oooh, I need to try that. How far back does that behavior go,
> compatibility-w
Alvaro Herrera writes:
> David E. Wheeler wrote:
>> Why can't anyelement be freed from this constraint?
> Because it would break other uses of it, I think.
Specifically, what are you going to do with something like
make_array(anyelement, anyelement) returns anyarray
There's no principl
On Sep 8, 2009, at 10:15 AM, Tom Lane wrote:
arg_a IS DISTINCT FROM arg_b
Surely you'd want arg_a and arg_b constrained to the same type,
otherwise there is no certainty that that means anything at all.
Yes, for the purposes of pgTAP perhaps so. Then it's on the user to do
the cast, be
On Tue, Sep 8, 2009 at 12:12 PM, Alvaro
Herrera wrote:
> Hi,
>
> I'm seeking more powerful "any" pseudotypes. In particular, consider a
> function
>
> foo(type1, type2) returns type3
>
> where type1 and type2 can be both any element type, but not necessarily
> both of the same type. Currently thi
"David E. Wheeler" writes:
> On Sep 8, 2009, at 9:57 AM, Tom Lane wrote:
>> Intentionally so, because there's not a whole lot you can *do* with an
>> ANY parameter, other than checking it for null. Perhaps the real
>> question is about what semantics you're expecting for these
>> unconstrained pa
On Sep 8, 2009, at 9:57 AM, Tom Lane wrote:
Intentionally so, because there's not a whole lot you can *do* with an
ANY parameter, other than checking it for null. Perhaps the real
question is about what semantics you're expecting for these
unconstrained parameters.
For my purposes, I guess im
Alvaro Herrera writes:
> Tom Lane wrote:
>> If you don't want any constraints at all on the argument types, you
>> can use "any" (with the quotes, because it's a reserved word :-().
> That would work, except that plpgsql and SQL don't like it:
Intentionally so, because there's not a whole lot yo
On Sep 8, 2009, at 9:32 AM, Alvaro Herrera wrote:
That would work, except that plpgsql and SQL don't like it:
ERROR: PL/pgSQL functions cannot accept type "any"
ERROR: SQL functions cannot have arguments of type "any"
Seems to go for other PLs, as well:
ERROR: PL/Perl functions cannot acc
Tom Lane wrote:
> Alvaro Herrera writes:
> > I'm seeking more powerful "any" pseudotypes.
>
> If you don't want any constraints at all on the argument types, you
> can use "any" (with the quotes, because it's a reserved word :-().
> If you want some constraints but not "anyelement", please be mor
On Sep 8, 2009, at 9:25 AM, Tom Lane wrote:
If you don't want any constraints at all on the argument types, you
can use "any" (with the quotes, because it's a reserved word :-().
If you want some constraints but not "anyelement", please be more
specific about what you want.
Oooh, I need to try
On Sep 8, 2009, at 9:23 AM, Alvaro Herrera wrote:
2. does anybody have an idea how to attack it?
Why can't anyelement be freed from this constraint?
Because it would break other uses of it, I think. IIRC the original
use
of anyelement was that it would resolve to the element type of an
Alvaro Herrera writes:
> I'm seeking more powerful "any" pseudotypes.
If you don't want any constraints at all on the argument types, you
can use "any" (with the quotes, because it's a reserved word :-().
If you want some constraints but not "anyelement", please be more
specific about what you wa
David E. Wheeler wrote:
> On Sep 8, 2009, at 9:12 AM, Alvaro Herrera wrote:
> >2. does anybody have an idea how to attack it?
>
> Why can't anyelement be freed from this constraint?
Because it would break other uses of it, I think. IIRC the original use
of anyelement was that it would resolve t
On Sep 8, 2009, at 9:12 AM, Alvaro Herrera wrote:
foo(anyelement, anyelement) returns anyelement
but this will force them to be both of the same type, which is not
what
we want. In my opinion this is a missing feature of our type system.
Oh yes, agreed. I've run into this with pgTAP many
Tom Lane wrote:
> Alvaro Herrera writes:
> > Should we inject some sort of compile-time rejection of the
> > compatibility API? Like, say
>
> > #ifdef AVAHI_SERVICE_COOKIE
> > #error The Avahi implementation is incompatible
> > #endif
>
> > inside some #ifdef BONJOUR block?
>
> I looked into t
Hi,
I'm seeking more powerful "any" pseudotypes. In particular, consider a
function
foo(type1, type2) returns type3
where type1 and type2 can be both any element type, but not necessarily
both of the same type. Currently this cannot be made to work: you could
try to write the function this way
Alvaro Herrera writes:
> Should we inject some sort of compile-time rejection of the
> compatibility API? Like, say
> #ifdef AVAHI_SERVICE_COOKIE
> #error The Avahi implementation is incompatible
> #endif
> inside some #ifdef BONJOUR block?
I looked into this and couldn't find any obvious cand
It would be nice if we could enable and disable column and table
constraints. I believe that you can do this in Oracle but this is very
handy for testing stored procedures and other external processes.
Best Regards
--
Michael Gould, Managing Partner
Intermodal Software Solutions, LLC
904.226.0978
>
> I personally suspect PostgreSQL would want a 1 year cycle for major
> releases while a full dump/reload is required for upgrades. When this
> changes, 6 or even 4 months might actually be a good fit.
>
For some DBA specialist is 1 year cycle too much fast. I thing, so 1
year cycle is perfect f
I wrote:
> I've grown a bit tired of reading the "'DNSServiceRegistrationCreate' is
> deprecated" warnings in OS X builds, and I'm also wondering whether any
> of the recently reported problems with Snow Leopard might trace to our
> use of an API that Apple has been deprecating since 2003. Hence,
Peter Eisentraut writes:
> On mån, 2009-09-07 at 23:13 -0400, Tom Lane wrote:
>> ... it seems to me that it's a pretty bad idea to have this switch
>> collection trying to override the arch(es) that Postgres is actually
>> being built for. Does anyone have an opinion about that pro or con?
>> An
Kristian
assuming the max size of 8 byte integer is
http://www.postgresql.org/docs/8.1/static/datatype.html
bigint8 byteslarge-range integer-9223372036854775808 to 9223372036854775807
i dont know if a IPV6 address
99 99 99 99would fit into
9,223,372,
David Fetter wrote:
> CREATE TRIGGER trig BEFORE UPDATE ON tbl FOR EACH ROW
> WHEN (NEW.col IS DISTINCT FROM OLD.col)
> EXECUTE PROCEDURE trigger_func();
How much does that buy you versus including this at the start of
trigger_func:
IF (NEW.col IS NOT DISTINCT FROM OLD.col) THEN
=?utf-8?Q?Pierre_Fr=C3=A9d=C3=A9ric_Caillau?= =?utf-8?Q?d?=
writes:
> * Here, the most negative value is sometimes accepted, sometimes not :
> test=> SELECT -2147483648::INTEGER;
> ERREUR: entier en dehors des limites
You're confused about the operator precedence: the above is
treated as -(214
On Tue, Sep 8, 2009 at 7:54 PM, Andrew Dunstan wrote:
> The release cycle is quite independent of the release lifetime.
If you have dates on releases, it is easier to set dates on release
lifetime. If you know the releases come out once a year at about the
same time, and you want to have a set nu
Andrew Dunstan writes:
> I would argue that it would be an major setback for us if we made
> another release without having Hot Standby or whatever we are calling it
> now. I would much rather slip one month or three than ship without it.
I would agree with you, except that every single time we
Itagaki Takahiro wrote:
>
> David Fetter wrote:
>
> > On Mon, Sep 07, 2009 at 12:15:21PM +0900, Itagaki Takahiro wrote:
> > > Here is a patch to implement the following items in our ToDo list:
> > > * Add CREATE TABLE LIKE ... INCLUDING COMMENTS
> > > * Have CREATE TABLE LIKE copy column sto
Stuart Bishop wrote:
Canonical (my employer) certainly believe in time based releases, and
that is one of the major reasons for the growth of Ubuntu and the
Ubuntu Community. We now use time based releases for almost all our
sponsored projects (some 6 monthly, some monthly), and are lobbying
va
On Sat, Aug 29, 2009 at 12:19 AM, Josh Berkus wrote:
> I'd think the advantages for our commercial adopters (who pay the
> salaries for many of the people on this list) would be obvious; if they
> know with a small margin of error when the next version of PostgreSQL is
> coming out, they can plan
I was looking in the int*in() functions and found some interesting limit
behaviours :
* Here, the most negative value is sometimes accepted, sometimes not :
test=> SELECT -2147483648::INTEGER;
ERREUR: entier en dehors des limites
test=> SELECT '-2147483648'::INTEGER;
int4
hi tom,
$ file /System/Library/Perl/lib/5.10/libperl.dylib
/System/Library/Perl/lib/5.10/libperl.dylib: Mach-O universal binary
with 3 architectures
/System/Library/Perl/lib/5.10/libperl.dylib (for architecture
x86_64): Mach-O 64-bit dynamically linked shared library x86_64
/System/Library/
hi tom,
Anyway, the long and the short of it is that we are extracting this
value for perl_embed_ldflags:
perl_embed_ldflags = -arch x86_64 -arch i386 -arch ppc -L/usr/
local/lib -L/System/Library/Perl/5.10.0/darwin-thread-multi-2level/
CORE -lperl -ldl -lm -lutil -lc
and it seems to
New patch, typo fix in pgc.l.
According to our customer who is porting their application
to PostgreSQL, this causes an error currently in ECPG:
1. within included structures the use of "$else;" is causing an
precompiler error (tested several times in d
68 matches
Mail list logo
