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 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.
EXCLUSION
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 out
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
On Thu, 2009-11-05 at 09:56 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
On tor, 2009-11-05 at 12:38 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
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 types to
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
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
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
On Thu, Nov 5, 2009 at 12:24 PM, Peter Eisentraut pete...@gmx.net 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
Andrew Dunstan and...@dunslane.net 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
Tom Lane t...@sss.pgh.pa.us 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
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
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
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,
Pavel Stehule pavel.steh...@gmail.com 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
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!
Well,
Merlin Moncure wrote:
On Thu, Nov 5, 2009 at 12:24 PM, Peter Eisentraut pete...@gmx.net 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
Peter Eisentraut pete...@gmx.net 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
On Thu, Nov 5, 2009 at 4:33 PM, Tom Lane t...@sss.pgh.pa.us 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:
On Thu, Nov 5, 2009 at 4:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net 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
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
2009/11/5 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
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 this? I
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 this?
27 matches
Mail list logo
