Re: [HACKERS] operator exclusion constraints

[David E. Wheeler]

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

[Jeff Davis]

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

[Jeff Davis]

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] Typed tables

[James Pye]

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

Re: [HACKERS] operator exclusion constraints

[Jeff Davis]

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 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

[Peter Eisentraut]

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 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] Typed tables

[Peter Eisentraut]

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

[HACKERS] Why do OLD and NEW have special internal names?

[Tom Lane]

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

[HACKERS] AFTER triggers RETURN

[Robert Haas]

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

Re: [HACKERS] AFTER triggers RETURN

[Andrew Dunstan]

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

Re: [HACKERS] Typed tables

[Merlin Moncure]

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 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

[Tom Lane]

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 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] Why do OLD and NEW have special internal names?

[Kevin Grittner]

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 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

[HACKERS] magic constant -1

[Pavel Stehule]

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

[HACKERS] plperl and inline functions -- first draft

[Joshua Tolley]

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,
+ codeblock-langOid);
+ }
+ langStruct = (Form_pg_language) 

Re: [HACKERS] plperl and inline functions -- first draft

[Andrew Dunstan]

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

Re: [HACKERS] magic constant -1

[Tom Lane]

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
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]

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] Typed tables

[Heikki Linnakangas]

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 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] Typed tables

[Itagaki Takahiro]

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 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] Why do OLD and NEW have special internal names?

[Robert Haas]

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: 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] AFTER triggers RETURN

[Robert Haas]

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 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

[HACKERS] Freebsd autoconf-2.63

[abindra]

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] magic constant -1

[Pavel Stehule]

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 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

Re: [HACKERS] Why do OLD and NEW have special internal names?

[Tom Lane]

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 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] Freebsd autoconf-2.63

[Heikki Linnakangas]

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] Freebsd autoconf-2.63

[Tom Lane]

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