Re: [HACKERS] Freebsd & autoconf-2.63
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? I posted a question > on the freebsd ports forum but have not had any solutions. Well, you could grab our nightly tarball instead of pulling from CVS. Or you could remove the version-check line from configure.in. The latter is actually very likely to work, we just don't promise anything (if it breaks, debugging is your problem not ours). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Freebsd & autoconf-2.63
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 posted a > question on the freebsd ports forum but have not had any solutions. Go to http://www.gnu.org/software/autoconf/, and download and install a newer version of autoconf. You shouldn't actually need to run autoconf even when building from a CVS checkout, because we keep the generated "configure" file in CVS as well. Unless you have edited configure.in, you can just do "./configure; make install" -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why do OLD and NEW have special internal names?
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 when >> this patch goes in. Doesn't bother me any, but if anyone thinks it's >> a serious problem, speak now. > Any keyword or just fully reserved keywords? Anything that's not allowed as a column name will be at issue. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] magic constant -1
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 the checks > for "unspecified" are coded as negative/nonnegative rather than > simple equality. I worked on enhancing an area where typmod is used, and I had a small problem - because it wasn't simply clean, where -1 is typmod or location. This should be an idea for enhancing and increasing code quality. -1 is probably last wide used magic constant in pg. Pavel > > regards, tom lane > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Freebsd & autoconf-2.63
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 the freebsd ports forum but have not had any solutions. Thanks Ashish -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] AFTER triggers & RETURN
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 you not fall off the end of a >> function unless it is declared to return void? The function doesn't know >> if it will be called before or after. > > Yeah, it couldn't be done as a compile-time check. You could probably > make it work if you converted the error to a run-time test. Not sure > if that's really an improvement though. Well, as it is, you don't get an error when you define the function, only when you do something that causes it to be invoked. An error when you define the function would probably be a small improvement, because at least it would be obvious that you'd broke something (and the transaction that tried to break it would roll back). No error at all seems better still. Perhaps in an ideal world before and after trigger functions would have different signatures - like the before trigger should perhaps take two rows as arguments and return a row, and the after trigger should take two rows as arguments and return void. The idea of overloading the function's return type to provide it with special, magical input parameters is pretty funky and means that you can't invoke that function in any context other than as a trigger, which would occasionally be useful. I think we're stuck with it at this point, but maybe it's possible to at least relax the requirement to explicitly return a useless result. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why do OLD and NEW have special internal names?
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 > + ^ > + QUERY: SELECT OLD > + CONTEXT: SQL statement in PL/PgSQL function "trigger_data" near line 35 > > The reason is that because plpgsql is no longer translating references > to its names into Params before letting the core parser see them, the > kluge in gram.y that changes "OLD" to "*OLD*" and "NEW" to "*NEW*" > kicks in, or actually decides to throw an error instead of kicking in. > > I am wondering what is the point at all of having that kluge. It > certainly doesn't manage to make OLD/NEW not act like reserved words, > in fact rather more the opposite, as shown here. If we just made those > names be ordinary table alias names in rule queries, wouldn't things > work as well or better? > > 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 when > this patch goes in. Doesn't bother me any, but if anyone thinks it's > a serious problem, speak now. Any keyword or just fully reserved keywords? ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Typed tables
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. > Think abstract base class. That's pretty much the idea. Come to think > of it, that's how the SQL standard defined inheritance. Sounds > interesting. And might actually be simpler to implement. Do you want to tightly bind the table with the underlying type? In other words, do you think "copying column definitions" is not enough? Like: CREATE TABLE employee (LIKE employee_data_type, LIKE persons_data_type); or CREATE TABLE employee () INHERITS (employee_data_type, persons_data_type); Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Typed tables
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 persons_type AS (name text, bdate date); >> >> CREATE TABLE persons OF persons_type; >> >> Or the fancy version: >> >> CREATE TABLE persons OF persons_type ( PRIMARY KEY (name) ); > > I use composite types (via tables) all the time but I never use > 'create type as'...because by doing so you lose the ability to alter > the type with 'alter table'. > > Am I correct that I could use your idea to make this possible (albeit > quite ugly) by: > > create type foo(a text, b text); > create table foo of foo; > alter table foo add column c text; > drop table foo; -- does this drop the type as well?? That seems weird. Seems we should forbid that, and have an ALTER TYPE command instead. I guess that means that we have to somehow memorize that the type and the table are distinct. Also, if you create a type and a table from it, pg_dump still needs to dump the CREATE TYPE command, not just CREATE TABLE. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] plperl and inline functions -- first draft
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, I warmed up with PL/LOLCODE :) >> 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 >> interpreter initialization works, and have simply copied what looked like >> important stuff from the original plperl call handler. >> > > I'll check that out. Many thanks. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [HACKERS] magic constant -1
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 coded as negative/nonnegative rather than simple equality. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] plperl and inline functions -- first draft
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, 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 interpreter initialization works, and have simply copied what looked like important stuff from the original plperl call handler. I'll check that out. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] plperl and inline functions -- first draft
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 interpreter initialization works, and have simply copied what looked like important stuff from the original plperl call handler. I tested with this to prove it: DO $$ qx{touch test.txt}; $$ language plperl; This works both with plperl and plperlu. Hints, anyone? Comments? -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com diff --git a/src/include/catalog/pg_pltemplate.h b/src/include/catalog/pg_pltemplate.h index 5ef97df..8cdedb4 100644 *** a/src/include/catalog/pg_pltemplate.h --- b/src/include/catalog/pg_pltemplate.h *** typedef FormData_pg_pltemplate *Form_pg_ *** 70,77 DATA(insert ( "plpgsql" t t "plpgsql_call_handler" "plpgsql_inline_handler" "plpgsql_validator" "$libdir/plpgsql" _null_ )); DATA(insert ( "pltcl" t t "pltcl_call_handler" _null_ _null_ "$libdir/pltcl" _null_ )); DATA(insert ( "pltclu" f f "pltclu_call_handler" _null_ _null_ "$libdir/pltcl" _null_ )); ! DATA(insert ( "plperl" t t "plperl_call_handler" _null_ "plperl_validator" "$libdir/plperl" _null_ )); ! DATA(insert ( "plperlu" f f "plperl_call_handler" _null_ "plperl_validator" "$libdir/plperl" _null_ )); DATA(insert ( "plpythonu" f f "plpython_call_handler" _null_ _null_ "$libdir/plpython" _null_ )); #endif /* PG_PLTEMPLATE_H */ --- 70,77 DATA(insert ( "plpgsql" t t "plpgsql_call_handler" "plpgsql_inline_handler" "plpgsql_validator" "$libdir/plpgsql" _null_ )); DATA(insert ( "pltcl" t t "pltcl_call_handler" _null_ _null_ "$libdir/pltcl" _null_ )); DATA(insert ( "pltclu" f f "pltclu_call_handler" _null_ _null_ "$libdir/pltcl" _null_ )); ! DATA(insert ( "plperl" t t "plperl_call_handler" "plperl_inline_handler" "plperl_validator" "$libdir/plperl" _null_ )); ! DATA(insert ( "plperlu" f f "plperl_call_handler" "plperl_inline_handler" "plperl_validator" "$libdir/plperl" _null_ )); DATA(insert ( "plpythonu" f f "plpython_call_handler" _null_ _null_ "$libdir/plpython" _null_ )); #endif /* PG_PLTEMPLATE_H */ diff --git a/src/pl/plperl/plperl.c b/src/pl/plperl/plperl.c index 4ed4f59..33ede1b 100644 *** a/src/pl/plperl/plperl.c --- b/src/pl/plperl/plperl.c *** static plperl_call_data *current_call_da *** 144,149 --- 144,150 * Forward declarations **/ Datum plperl_call_handler(PG_FUNCTION_ARGS); + Datum plperl_inline_handler(PG_FUNCTION_ARGS); Datum plperl_validator(PG_FUNCTION_ARGS); void _PG_init(void); *** plperl_modify_tuple(HV *hvTD, TriggerDat *** 862,870 /* ! * This is the only externally-visible part of the plperl call interface. ! * The Postgres function and trigger managers call it to execute a ! * perl function. */ PG_FUNCTION_INFO_V1(plperl_call_handler); --- 863,872 /* ! * plperl_call_handler and plperl_inline_handler are the only ! * externally-visible parts of the plperl call interface. The Postgres function ! * and trigger managers call plperl_call_handler to execute a perl function, and ! * call plperl_inline_handler to execute plperl code in a DO statement. */ PG_FUNCTION_INFO_V1(plperl_call_handler); *** plperl_call_handler(PG_FUNCTION_ARGS) *** 895,900 --- 897,952 return retval; } + PG_FUNCTION_INFO_V1(plperl_inline_handler); + + Datum + plperl_inline_handler(PG_FUNCTION_ARGS) + { + InlineCodeBlock *codeblock = (InlineCodeBlock *) DatumGetPointer(PG_GETARG_DATUM(0)); + FunctionCallInfoData fake_fcinfo; + FmgrInfo flinfo; + plperl_proc_desc desc; + HeapTuple langTup; + Form_pg_language langStruct; + + MemSet(&fake_fcinfo, 0, sizeof(fake_fcinfo)); + MemSet(&flinfo, 0, sizeof(flinfo)); + MemSet(&desc, 0, sizeof(desc)); + fake_fcinfo.flinfo = &flinfo; + flinfo.fn_oid = InvalidOid; + flinfo.fn_mcxt = CurrentMemoryContext; + + desc.proname = ""; + desc.fn_readonly = 0; + + / + * Lookup the pg_language tuple by Oid + / + langTup = SearchSysCache(LANGOID, + ObjectIdGetDatum(codeblock->langOid), + 0, 0, 0); + if (!HeapTupleIsValid(langTup)) + { + elog(ERROR, "cache lookup failed for language with OID %d",
[HACKERS] magic constant -1
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 to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why do OLD and NEW have special internal names?
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 serious problem, speak now. As long as I can use anything I want when it's quoted, I don't care. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] AFTER triggers & RETURN
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 declared to return void? The function doesn't know > if it will be called before or after. Yeah, it couldn't be done as a compile-time check. You could probably make it work if you converted the error to a run-time test. Not sure if that's really an improvement though. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Typed tables
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 date); > > CREATE TABLE persons OF persons_type; > > Or the fancy version: > > CREATE TABLE persons OF persons_type ( PRIMARY KEY (name) ); I use composite types (via tables) all the time but I never use 'create type as'...because by doing so you lose the ability to alter the type with 'alter table'. Am I correct that I could use your idea to make this possible (albeit quite ugly) by: create type foo(a text, b text); create table foo of foo; alter table foo add column c text; drop table foo; -- does this drop the type as well?? merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] AFTER triggers & RETURN
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 foo for each row execute procedure broken(); insert into foo values (1); ERROR: control reached end of trigger procedure without RETURN CONTEXT: PL/pgSQL function "broken" 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 declared to return void? The function doesn't know if it will be called before or after. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] AFTER triggers & RETURN
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 execute procedure broken(); insert into foo values (1); ERROR: control reached end of trigger procedure without RETURN CONTEXT: PL/pgSQL function "broken" 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. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Why do OLD and NEW have special internal names?
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 statement in PL/PgSQL function "trigger_data" near line 35 The reason is that because plpgsql is no longer translating references to its names into Params before letting the core parser see them, the kluge in gram.y that changes "OLD" to "*OLD*" and "NEW" to "*NEW*" kicks in, or actually decides to throw an error instead of kicking in. I am wondering what is the point at all of having that kluge. It certainly doesn't manage to make OLD/NEW not act like reserved words, in fact rather more the opposite, as shown here. If we just made those names be ordinary table alias names in rule queries, wouldn't things work as well or better? 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 when this patch goes in. Doesn't bother me any, but if anyone thinks it's a serious problem, speak now. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Typed tables
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 participate in inheritance relationships. Think abstract base class. That's pretty much the idea. Come to think of it, that's how the SQL standard defined inheritance. Sounds interesting. And might actually be simpler to implement. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Typed tables
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 original composite type are > independent, or are still tied together --- ie, does ALTER TABLE ADD > COLUMN or similar affect the composite type? They need to stay tied together. But it's to be determined whether ALTER TABLE ADD COLUMN would work on those tables or whether there would be some kind of ALTER TYPE. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] operator exclusion constraints
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 there aren't perfect, either. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] operator exclusion constraints
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 is vague about what is doing the excluding and what is being excluded. I think that's good in this case, because the actual meaning can't easily be expressed with a couple keywords, so suggesting the behavior is about as close as we can get (unless someone comes up with a new idea). > EXCLUDING (...) BY ... I think that's better, but still sounds a little wrong to me. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] operator exclusion constraints
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" ("EXCLUDING USING gist" is a little weirder). Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] operator exclusion constraints
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. > EXCLUSIVE still feels like the wrong part-of-speech though. How > about EXCLUDING (...) BY ... instead? 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. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Typed tables
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 same name" +1 for keeping it. Thoughts? Any plans to allow the specification of multiple types to define the table? "CREATE TABLE employee OF employee_data_type, persons_data_type;" -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers