abin...@u.washington.edu writes:
> I downloaded the latest postgresql code via cvs on a FreeBSD 7.2 system. When
> I try to run autoconf on the source it tells me that I need autoconf-2.63.
> However the freeBSD ports only has autoconf-6.62.
> Does anyone have any suggestion on how to resolve th
abin...@u.washington.edu wrote:
> I downloaded the latest postgresql code via cvs on a FreeBSD 7.2 system.
> When I try to run autoconf on the source it tells me that I need
> autoconf-2.63. However the freeBSD ports only has autoconf-6.62.
>
> Does anyone have any suggestion on how to resolve thi
Robert Haas writes:
>> BTW, this brings up another point, which is that up to now it's often
>> been possible to use plpgsql variable names that conflict with
>> core-parser reserved words, so long as you didn't need to use the
>> reserved word with its special meaning. That will stop working whe
2009/11/5 Tom Lane :
> Pavel Stehule writes:
>> we use a value -1 as two values: a) unknown typmod, b) unknown
>> location. Can we substitute it by some better identifier?
>
>> Maybe: UnknownTmod, UnknownLoc ... UnspecTmd, UnspecLoc???
>
> Doesn't really seem worth the trouble, especially since th
Hi there,
I downloaded the latest postgresql code via cvs on a FreeBSD 7.2 system. When I
try to run autoconf on the source it tells me that I need autoconf-2.63.
However the freeBSD ports only has autoconf-6.62.
Does anyone have any suggestion on how to resolve this? I posted a question on
On Thu, Nov 5, 2009 at 4:57 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Robert Haas wrote:
>>> Since the return value is ignored anyway, why do we have to complain
>>> if it's left out altogether? Granted, it's easy to work around, but
>>> still.
>
>> Isn't is a requirement of plpgsql that y
On Thu, Nov 5, 2009 at 4:33 PM, Tom Lane wrote:
> So I was testing the next step of plpgsql modification, namely actually
> letting the parser hooks do something, and it promptly blew up in
> trigger functions, like so:
>
> + ERROR: OLD used in query that is not in a rule
> + LINE 1: SELECT OLD
Peter Eisentraut wrote:
> On tor, 2009-11-05 at 11:41 -0700, James Pye wrote:
> >"CREATE TABLE employee OF employee_data_type, persons_data_type;"
>
> Not really, but it does open up interesting possibilities, if we just
> allow composite types to participate in inheritance relationships.
>
Merlin Moncure wrote:
> On Thu, Nov 5, 2009 at 12:24 PM, Peter Eisentraut wrote:
>> I'm planning to work on typed tables support. The idea is that you
>> create a table out of a composite type (as opposed to the other way
>> around, which is currently done automatically).
>>
>> CREATE TYPE person
On Thu, Nov 05, 2009 at 05:51:45PM -0500, Andrew Dunstan wrote:
> Joshua Tolley wrote:
>> I've been trying to make pl/perl support 8.5's inline functions, with the
>> attached patch.
>
> Wow, this is the second time this week that people have produced patches
> for stuff I was about to do. Cool!
Pavel Stehule writes:
> we use a value -1 as two values: a) unknown typmod, b) unknown
> location. Can we substitute it by some better identifier?
> Maybe: UnknownTmod, UnknownLoc ... UnspecTmd, UnspecLoc???
Doesn't really seem worth the trouble, especially since the checks
for "unspecified" are
Joshua Tolley wrote:
I've been trying to make pl/perl support 8.5's inline functions, with the
attached patch.
Wow, this is the second time this week that people have produced patches
for stuff I was about to do. Cool!
The basics seem to be there, with at least one notable
exception, nam
I've been trying to make pl/perl support 8.5's inline functions, with the
attached patch. The basics seem to be there, with at least one notable
exception, namely that plperl functions can do stuff only plperlu should do. I
presume this is because I really don't understand yet how plperl's trusted
Hello,
we use a value -1 as two values: a) unknown typmod, b) unknown
location. Can we substitute it by some better identifier?
Maybe: UnknownTmod, UnknownLoc ... UnspecTmd, UnspecLoc???
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Tom Lane wrote:
> been possible to use plpgsql variable names that conflict with
> core-parser reserved words, so long as you didn't need to use the
> reserved word with its special meaning. That will stop working when
> this patch goes in. Doesn't bother me any, but if anyone thinks
it's
> a
Andrew Dunstan writes:
> Robert Haas wrote:
>> Since the return value is ignored anyway, why do we have to complain
>> if it's left out altogether? Granted, it's easy to work around, but
>> still.
> Isn't is a requirement of plpgsql that you not fall off the end of a
> function unless it is dec
On Thu, Nov 5, 2009 at 12:24 PM, Peter Eisentraut wrote:
> I'm planning to work on typed tables support. The idea is that you
> create a table out of a composite type (as opposed to the other way
> around, which is currently done automatically).
>
> CREATE TYPE persons_type AS (name text, bdate d
Robert Haas wrote:
Tom's recent work to fix the (TG_OP = 'INSERT' and NEW.foo ...)
problem reminded me of another PL/pgsql annoyance:
create table foo (a integer);
create or replace function broken() returns trigger as $$begin perform
1; end$$ language plpgsql;
create trigger bar after insert
Tom's recent work to fix the (TG_OP = 'INSERT' and NEW.foo ...)
problem reminded me of another PL/pgsql annoyance:
create table foo (a integer);
create or replace function broken() returns trigger as $$begin perform
1; end$$ language plpgsql;
create trigger bar after insert on foo for each row exe
So I was testing the next step of plpgsql modification, namely actually
letting the parser hooks do something, and it promptly blew up in
trigger functions, like so:
+ ERROR: OLD used in query that is not in a rule
+ LINE 1: SELECT OLD
+ ^
+ QUERY: SELECT OLD
+ CONTEXT: SQL st
On tor, 2009-11-05 at 11:41 -0700, James Pye wrote:
> Any plans to allow the specification of multiple types to define the
> table?
>
>"CREATE TABLE employee OF employee_data_type, persons_data_type;"
Not really, but it does open up interesting possibilities, if we just
allow composite type
On tor, 2009-11-05 at 12:38 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > One thing I'm not sure of is whether to keep the implicit row type in
> > that case. That is, would the above command sequence still create a
> > "persons" type?
>
> Are you intending that the table and the origina
On Thu, 2009-11-05 at 11:16 -0800, David E. Wheeler wrote:
> Well that's clearly a verb. So perhaps "EXCLUDE USING
> gist" ("EXCLUDING USING gist" is a little weirder).
That's not bad.
As I just said in my other email, I think the word EXCLUDE is a little
bit too specific, but the other ideas o
On Thu, 2009-11-05 at 10:30 -0800, David E. Wheeler wrote:
> But that doesn't read as well to my eye as:
>
> EXCLUDE (...) BY ...
I think EXCLUDE might be a little *too* specific. It sounds like
whatever is on the right hand side will be excluded, but that's not
really what happens.
EXCLUSI
On Nov 5, 2009, at 11:09 AM, Jeff Davis wrote:
I think EXCLUDING conflicts with the EXCLUDING in LIKE. Also, it
becomes
a little more difficult to place the access method clause, because
"EXCLUDING USING gist" doesn't sound great.
Well that's clearly a verb. So perhaps "EXCLUDE USING
gist"
On Thu, 2009-11-05 at 09:56 -0500, Tom Lane wrote:
> Robert Haas writes:
> > Ooh, that's kind of neat. But I think you'd need EXCLUSIVE (a, b) BY
> > (=, =), since it could equally well be EXCLUSIVE (a, b) BY (=, &&).
>
> Yeah, we definitely want some parentheses delimiting the expression.
> EXC
On Nov 5, 2009, at 10:24 AM, Peter Eisentraut wrote:
One thing I'm not sure of is whether to keep the implicit row type in
that case. That is, would the above command sequence still create a
"persons" type? We could keep that so as to preserve the property "a
table always has a row type of the
27 matches
Mail list logo
