Re: [HACKERS] WIP: RangeTypes

[Thom Brown]

On 30 January 2011 02:55, Thom Brown  wrote:
> On 29 January 2011 19:53, Jeff Davis  wrote:
>> On Sat, 2011-01-29 at 14:42 -0500, Tom Lane wrote:
>>> Jeff Davis  writes:
>>> > On Fri, 2011-01-28 at 21:52 +, Thom Brown wrote:
>>> > Also, if I try the same, but with a different name for the type, I get
>>> > the same error.  Why does that restriction exist?  Can't you have
>>> > types which happen to use the exact same subtype?
>>>
>>> > At first, that's how I designed it. Then, I realized that the type
>>> > system needs to know the range type from the element type in order for
>>> > something like ANYRANGE to work.
>>>
>>> That seems like a fairly bad restriction.  In a datatype with multiple
>>> useful sort orderings, it'd be desirable to be able to create a range
>>> type for each such ordering, no?  I'd be inclined to think of a range
>>> type as being defined by element type plus a btree opfamily.  Maybe it'd
>>> be okay to insist on that combination as being unique.
>>
>> I couldn't find another way to make a function with a definition like:
>>
>>  range(ANYELEMENT, ANYELEMENT) returns ANYRANGE
>>
>> work. And it seemed worse to live without a constructor like that.
>> Ideas?
>>
>> Also, it's not based on the btree opfamily right now. It's just based on
>> a user-supplied compare function. I think I could change it to store the
>> opfamily instead, if you think that's a better idea.
>
> Probably ignorance here, but why does the following not work?
>
> postgres=# select '[18,20]'::numrange @> 19;
> ERROR:  operator does not exist: numrange @> integer
> LINE 1: select '[18,20]'::numrange @> 19;
>                                   ^
> HINT:  No operator matches the given name and argument type(s). You
> might need to add explicit type casts.
>
>
> I can see both the wiki page on range types and the pg_operator table
> appear to indicate this should work:
>
> postgres=# select o.oprname, tl.typname as lefttype, tr.typname as
> righttype from pg_operator o left join pg_type tl on o.oprleft =
> tl.oid left join pg_type tr on o.oprright = tr.oid where 'anyrange' in
> (tl.typname, tr.typname) and oprname = '@>';
>  oprname | lefttype |  righttype
> -+--+-
>  @>      | anyrange | anynonarray
>  @>      | anyrange | anyrange
> (2 rows)

As for docs, anyrange will need mentioning as part of the information
about polymorphic types:
http://developer.postgresql.org/pgdocs/postgres/extend-type-system.html

And on the pseudo-types page:
http://developer.postgresql.org/pgdocs/postgres/datatype-pseudo.html

-- 
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

-- 
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] WIP: RangeTypes

[Thom Brown]

On 29 January 2011 19:53, Jeff Davis  wrote:
> On Sat, 2011-01-29 at 14:42 -0500, Tom Lane wrote:
>> Jeff Davis  writes:
>> > On Fri, 2011-01-28 at 21:52 +, Thom Brown wrote:
>> > Also, if I try the same, but with a different name for the type, I get
>> > the same error.  Why does that restriction exist?  Can't you have
>> > types which happen to use the exact same subtype?
>>
>> > At first, that's how I designed it. Then, I realized that the type
>> > system needs to know the range type from the element type in order for
>> > something like ANYRANGE to work.
>>
>> That seems like a fairly bad restriction.  In a datatype with multiple
>> useful sort orderings, it'd be desirable to be able to create a range
>> type for each such ordering, no?  I'd be inclined to think of a range
>> type as being defined by element type plus a btree opfamily.  Maybe it'd
>> be okay to insist on that combination as being unique.
>
> I couldn't find another way to make a function with a definition like:
>
>  range(ANYELEMENT, ANYELEMENT) returns ANYRANGE
>
> work. And it seemed worse to live without a constructor like that.
> Ideas?
>
> Also, it's not based on the btree opfamily right now. It's just based on
> a user-supplied compare function. I think I could change it to store the
> opfamily instead, if you think that's a better idea.

Probably ignorance here, but why does the following not work?

postgres=# select '[18,20]'::numrange @> 19;
ERROR:  operator does not exist: numrange @> integer
LINE 1: select '[18,20]'::numrange @> 19;
   ^
HINT:  No operator matches the given name and argument type(s). You
might need to add explicit type casts.


I can see both the wiki page on range types and the pg_operator table
appear to indicate this should work:

postgres=# select o.oprname, tl.typname as lefttype, tr.typname as
righttype from pg_operator o left join pg_type tl on o.oprleft =
tl.oid left join pg_type tr on o.oprright = tr.oid where 'anyrange' in
(tl.typname, tr.typname) and oprname = '@>';
 oprname | lefttype |  righttype
-+--+-
 @>  | anyrange | anynonarray
 @>  | anyrange | anyrange
(2 rows)

-- 
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

-- 
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] Change pg_last_xlog_receive_location not to move backwards

[Jeff Janes]

On Tue, Jan 25, 2011 at 6:38 PM, Fujii Masao  wrote:

>> The third seems more problematic.  In the XLogPageRead,
>> it checks to see if more records have been received beyond what
>> has been applied.  By using the non-retreating value here, it seems
>> like the xlog replay could start replaying records that the wal
>> receiver is in the process of overwriting.  Now, I've argued to myself
>> that this is not a problem, because the receiver is overwriting them
>> with identical data to that which is already there.
>
> Yes. I don't think that it's a problem, too.
>
>> But by that logic, why does any part of it (walrcv->receiveStart in
>> the patch, walrcv->receivedUpto unpatched) need to retreat?  From
>> the previous discussion, I understand that the concern is that we don't
>> want to retrieve and write out partial xlog files.  What I don't understand
>> is how we could get our selves into the position in which we are doing
>> that, other than by someone going in and doing impermissible things to
>> the PGDATA directory behind our backs.
>
> That logic exists because we'd like to check that newly-received WAL
> data is consistent with previous one by validating the header of new
> WAL file.

I do not understand what doing so gets us.

Say we previously received 2/3 of a WAL file, and replayed most of it.
So now the shared buffers have data that has been synced to that WAL
file already, and some of those dirty shared buffers have been written
to disk and some have not.  At this point, we need the data in the first
2/3 of the WAL file in order to reach a consistent state.  But now we
lose the connection to the master, and then we restore it.  Now we
request the entire file from the start rather than from where it
left off.

Either of two things happens.  Most likely, the newly received WAL file
matches the file it is overwriting, in which case there was no
point in asking for it.

Less likely, the master is feeding us gibberish.  By requesting the
full WAL file, we check the header and detect that the master is feeding
us gibberish.  Unfortunately, we only detect that fact *after* we have
replaced a critical part of our own (previously good) copy of the WAL
file with said gibberish.  The standby is now in an unrecoverable state.

With a bit of malicious engineering, I have created this situation.
I don't know how likely it is that something like that could happen
accidentally, say with a corrupted file system.  I have been unable
to engineer a situation where checking the header actually does
any good.  It has either done nothing, or done harm.



> So since we need the header of new WAL file, we retreat the
> replication starting location to the beginning of the WAL file when
> reconnecting to the primary.
>
> The following code (in XLogPageRead) validates the header of new
> WAL file.
>
> --
>        if (switched_segment && targetPageOff != 0)
>        {
>                /*
>                 * Whenever switching to a new WAL segment, we read the first 
> page of
>                 * the file and validate its header, even if that's not where 
> the
>                 * target record is.  This is so that we can check the 
> additional
>                 * identification info that is present in the first page's 
> "long"
>                 * header.
>                 */
>                readOff = 0;
>                if (read(readFile, readBuf, XLOG_BLCKSZ) != XLOG_BLCKSZ)
>                {
>                        ereport(emode_for_corrupt_record(emode, *RecPtr),
>                                        (errcode_for_file_access(),
>                                         errmsg("could not read from log file 
> %u, segment %u, offset %u: %m",
>                                                        readId, readSeg, 
> readOff)));
>                        goto next_record_is_invalid;
>                }
>                if (!ValidXLOGHeader((XLogPageHeader) readBuf, emode))
>                        goto next_record_is_invalid;
>        }


OK, thanks for the explanation.  Is there a race condition here?  That is,
it seems that with your patch this part of the code could get executed
after streaming is restarted, but before the streaming ever actually received
and wrote anything.  So it would be checking the old header, not the newly
about-to-be received header.

Cheers,

Jeff

-- 
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] [Mingw-users] mingw64

[Andrew Dunstan]

On 01/29/2011 08:26 AM, Peter Rosin wrote:

Maybe that's true. But Windows doesn't come wth zic nor a timezone
database like Unix usually has. Part of the reason we started
maintaining our own timezone sets was that we needed it on Windows. And
since we do mke rovision for that, jumping through these hoops seems
silly. I'm much more interested in building 64 bit Postgres for Windows
natively than as a cross compilation, and as I reported yesterday, it's
entirely possible. The cross-compilaion without renaming failed
miserably on my setuo, because, for example, configure used the wrong ar.


*** Moving thread to mingw-w64-public ***

There is/was a bug in autotools, where the wrong AR was used, try adding
"AC_CHECK_TOOL([AR], [ar], [:])" as a workaround.

Hi,

I am probably missing something, but from a message posted previously
in this thread [1] I find this:


Invocation command line was

  $ ./configure --without-zlib --host=x86_64-w64-mingw32 --prefix=D:/psqlbin




Yeah, this is working for me now. I don't know what went wrong previously.

Thanks for following up.

But the point remains that using --with-system-tzdata is silly on 
Windows. If you're cross-compiling (e.g. building 64bit Postgres on 
32bit Windows), your best bet is probably to build natively and use the 
zic.exe from the native build.  If you're only bulding to get the client 
libraries I guess it doesn't matter, but otherwise it sure does.


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] [Mingw-users] mingw64

[Peter Rosin]

>> Maybe that's true. But Windows doesn't come wth zic nor a timezone
>> database like Unix usually has. Part of the reason we started
>> maintaining our own timezone sets was that we needed it on Windows. And
>> since we do mke rovision for that, jumping through these hoops seems
>> silly. I'm much more interested in building 64 bit Postgres for Windows
>> natively than as a cross compilation, and as I reported yesterday, it's
>> entirely possible. The cross-compilaion without renaming failed
>> miserably on my setuo, because, for example, configure used the wrong ar.
>>
> 
> *** Moving thread to mingw-w64-public ***
> 
> There is/was a bug in autotools, where the wrong AR was used, try adding
> "AC_CHECK_TOOL([AR], [ar], [:])" as a workaround.

Hi,

I am probably missing something, but from a message posted previously
in this thread [1] I find this:

>Invocation command line was
>
>  $ ./configure --without-zlib --host=x86_64-w64-mingw32 --prefix=D:/psqlbin

And the following snippets in config.log:

>configure:6164: checking for x86_64-w64-mingw32-ar
>configure:6180: found /mingw/bin/x86_64-w64-mingw32-ar
>configure:6191: result: x86_64-w64-mingw32-ar

this when listing cache variables:

>ac_cv_prog_AR=x86_64-w64-mingw32-ar

and this when listing output variables:

>AR='x86_64-w64-mingw32-ar'

Exactly how is x86_64-w64-mingw32-ar the wrong ar?
Or is plain 'ar' used somewhere instead of 'x86_64-w64-mingw32-ar'?

Cheers,
Peter

[1] http://permalink.gmane.org/gmane.comp.db.postgresql.devel.general/159184

-- 
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] pl/python SPI in subtransactions

[Jan Urbański]

On 29/01/11 22:10, Steve Singer wrote:
> On 11-01-29 03:39 PM, Jan Urbański wrote:
>>
>> D'oh, you're right, thanks. Attached patch with fix. Curiosly, right now
>> in master your example with plpy.prepare will result in "savepoint"
>> being swallowed, but it's of course better to react with an error.
>>
>> Cheers,
>> Jan
> 
> This seems to fix it.
> 
> You mentioned that you were going to add a few paragraphs to the
> documentation saying that you can now actually catch SPI errors. I
> haven't seen that yet.

Yeah, I'm procrastinating the doc writing part ;) Will spit something
out by the end of the (CET) day.

> Other than that I don't see any issues with the patch and it should be
> ready for a committer.

Great, thanks for a diligent review,
Jan

-- 
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] pl/python SPI in subtransactions

[Steve Singer]

On 11-01-29 03:39 PM, Jan Urbański wrote:


D'oh, you're right, thanks. Attached patch with fix. Curiosly, right now
in master your example with plpy.prepare will result in "savepoint"
being swallowed, but it's of course better to react with an error.

Cheers,
Jan


This seems to fix it.

You mentioned that you were going to add a few paragraphs to the 
documentation saying that you can now actually catch SPI errors. I 
haven't seen that yet.


Other than that I don't see any issues with the patch and it should be 
ready for a committer.









--
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] pl/python SPI in subtransactions

[Jan Urbański]

On 29/01/11 21:27, Steve Singer wrote:
> On 11-01-27 04:33 PM, Jan Urbański wrote:
>>> I am finding the treatment of savepoints very strange.
>>> If as a function author I'm able to recover from errors then I'd expect
>>> (or maybe want) to be able to manage them through savepoints
>> Ooops, you found a bug there. In the attached patch you get the same
>> error (SPI_ERROR_TRANSACTION) as in master. Also added a unit test for
>> that.
>>
> I think you need to make the same change to PLy_spi_execute_plan.

D'oh, you're right, thanks. Attached patch with fix. Curiosly, right now
in master your example with plpy.prepare will result in "savepoint"
being swallowed, but it's of course better to react with an error.

Cheers,
Jan
diff --git a/src/pl/plpython/expected/plpython_error.out b/src/pl/plpython/expected/plpython_error.out
index ea4a54c..c8ce984 100644
*** a/src/pl/plpython/expected/plpython_error.out
--- b/src/pl/plpython/expected/plpython_error.out
*** CREATE FUNCTION sql_syntax_error() RETUR
*** 8,15 
  'plpy.execute("syntax error")'
  LANGUAGE plpythonu;
  SELECT sql_syntax_error();
- WARNING:  plpy.SPIError: unrecognized error in PLy_spi_execute_query
- CONTEXT:  PL/Python function "sql_syntax_error"
  ERROR:  plpy.SPIError: syntax error at or near "syntax"
  LINE 1: syntax error
  ^
--- 8,13 
*** CREATE FUNCTION exception_index_invalid_
*** 32,39 
  return rv[0]'
  	LANGUAGE plpythonu;
  SELECT exception_index_invalid_nested();
- WARNING:  plpy.SPIError: unrecognized error in PLy_spi_execute_query
- CONTEXT:  PL/Python function "exception_index_invalid_nested"
  ERROR:  plpy.SPIError: function test5(unknown) does not exist
  LINE 1: SELECT test5('foo')
 ^
--- 30,35 
*** return None
*** 54,61 
  '
  	LANGUAGE plpythonu;
  SELECT invalid_type_uncaught('rick');
- WARNING:  plpy.SPIError: unrecognized error in PLy_spi_prepare
- CONTEXT:  PL/Python function "invalid_type_uncaught"
  ERROR:  plpy.SPIError: type "test" does not exist
  CONTEXT:  PL/Python function "invalid_type_uncaught"
  /* for what it's worth catch the exception generated by
--- 50,55 
*** return None
*** 77,84 
  '
  	LANGUAGE plpythonu;
  SELECT invalid_type_caught('rick');
- WARNING:  plpy.SPIError: unrecognized error in PLy_spi_prepare
- CONTEXT:  PL/Python function "invalid_type_caught"
  NOTICE:  type "test" does not exist
  CONTEXT:  PL/Python function "invalid_type_caught"
   invalid_type_caught 
--- 71,76 
*** return None
*** 104,111 
  '
  	LANGUAGE plpythonu;
  SELECT invalid_type_reraised('rick');
- WARNING:  plpy.SPIError: unrecognized error in PLy_spi_prepare
- CONTEXT:  PL/Python function "invalid_type_reraised"
  ERROR:  plpy.Error: type "test" does not exist
  CONTEXT:  PL/Python function "invalid_type_reraised"
  /* no typo no messing about
--- 96,101 
*** SELECT valid_type('rick');
*** 126,128 
--- 116,140 
   
  (1 row)
  
+ /* manually starting subtransactions - a bad idea
+  */
+ CREATE FUNCTION manual_subxact() RETURNS void AS $$
+ plpy.execute("savepoint save")
+ plpy.execute("create table foo(x integer)")
+ plpy.execute("rollback to save")
+ $$ LANGUAGE plpythonu;
+ SELECT manual_subxact();
+ ERROR:  plpy.SPIError: SPI_execute failed: SPI_ERROR_TRANSACTION
+ CONTEXT:  PL/Python function "manual_subxact"
+ /* same for prepared plans
+  */
+ CREATE FUNCTION manual_subxact_prepared() RETURNS void AS $$
+ save = plpy.prepare("savepoint save")
+ rollback = plpy.prepare("rollback to save")
+ plpy.execute(save)
+ plpy.execute("create table foo(x integer)")
+ plpy.execute(rollback)
+ $$ LANGUAGE plpythonu;
+ SELECT manual_subxact_prepared();
+ ERROR:  plpy.SPIError: SPI_execute_plan failed: SPI_ERROR_TRANSACTION
+ CONTEXT:  PL/Python function "manual_subxact_prepared"
diff --git a/src/pl/plpython/plpython.c b/src/pl/plpython/plpython.c
index aafe556..6d3566a 100644
*** a/src/pl/plpython/plpython.c
--- b/src/pl/plpython/plpython.c
*** typedef int Py_ssize_t;
*** 101,106 
--- 101,107 
  #include "nodes/makefuncs.h"
  #include "parser/parse_type.h"
  #include "tcop/tcopprot.h"
+ #include "access/xact.h"
  #include "utils/builtins.h"
  #include "utils/hsearch.h"
  #include "utils/lsyscache.h"
*** PLy_spi_prepare(PyObject *self, PyObject
*** 2817,2822 
--- 2818,2824 
  	char	   *query;
  	void	   *tmpplan;
  	volatile MemoryContext oldcontext;
+ 	volatile ResourceOwner oldowner;
  	int			nargs;
  
  	if (!PyArg_ParseTuple(args, "s|O", &query, &list))
*** PLy_spi_prepare(PyObject *self, PyObject
*** 2840,2845 
--- 2842,2852 
  	plan->args = nargs ? PLy_malloc(sizeof(PLyTypeInfo) * nargs) : NULL;
  
  	oldcontext = CurrentMemoryContext;
+ 	oldowner = CurrentResourceOwner;
+ 
+ 	BeginInternalSubTransaction(NULL);
+ 	MemoryContextSwitchTo(oldcontext);
+ 
  	PG_TRY();
  	{
  		int	i;
*** PLy_spi_prepare(PyObject

Re: [HACKERS] pl/python SPI in subtransactions

[Steve Singer]

On 11-01-27 04:33 PM, Jan Urbański wrote:


Right, without the patch you can never catch errors originating from
plpy.execute, so any error terminates the whole function, and so rolls
back the statement. FWIW PL/Perl works the same:

begin;
create table foo(i int primary key);
DO $$
spi_exec_query("insert into foo values ('1')");
eval { spi_exec_query("insert into foo values ('1')"); };
elog(LOG, $@) if $@;
$$ language plperl;
select * from foo;

You will see a row in foo. AFAICS PL/Tcl also does it, but I don't have
it complied it to try. It does consitute a behaviour change, but we
didn't get any complains when the same thing happened for Perl.



If we've made this type of behaviour change for pl/perl and no one 
complained then I don't see an issue with doing it for plpython (if 
anyone does they should speak up)




I am finding the treatment of savepoints very strange.
If as a function author I'm able to recover from errors then I'd expect
(or maybe want) to be able to manage them through savepoints

Ooops, you found a bug there. In the attached patch you get the same
error (SPI_ERROR_TRANSACTION) as in master. Also added a unit test for that.


I think you need to make the same change to PLy_spi_execute_plan.

Try

BEGIN;
create table foo(a int4 primary key);
DO $$
prep=plpy.prepare("savepoint save")
plpy.execute(prep)
r=plpy.execute("insert into foo values ('1')")
try :
  r=plpy.execute("insert into foo values ('1')")
except:
  prep=plpy.prepare("rollback to save")
  plpy.execute(prep)
  plpy.log("something went wrong")
$$ language plpythonu;



--
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] SPI_exec doesn't return proc context (on 9.1)

[Pavel Stehule]

2011/1/29 Tom Lane :
> Pavel Stehule  writes:
>> I am playing with demos for PostgreSQL's Prague Developer Day and I
>> found a strange behave. SPI_exec should to return to proc context. But
>> it isn't true.
>
> Yes it is.

ah, I though a savedctx, but it restore procctx, that is child context
 of SPI too.

>
>> In following demo, I have to play with MemoryContext
>> when I would to get a correct result. Is it ok?
>
> The commented-out lines of code don't appear to have anything to do with
> what you claim the problem is.  What it looks to me like you're doing is
> copying the result out to the function's calling context, which is not
> either of the SPI contexts established by SPI_connect (and removed by
> SPI_finish).

>
> The less crocky way to do that is to use SPI_palloc() for something that
> should be allocated in the outer context.

I understand. Is there some way, where I can use a cstring_to_text
function? There isn't simple way to get a saveCtx.

some like SPI_copyDatum ... ?

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] WIP: RangeTypes

[Jeff Davis]

On Sat, 2011-01-29 at 14:42 -0500, Tom Lane wrote:
> Jeff Davis  writes:
> > On Fri, 2011-01-28 at 21:52 +, Thom Brown wrote:
> > Also, if I try the same, but with a different name for the type, I get
> > the same error.  Why does that restriction exist?  Can't you have
> > types which happen to use the exact same subtype?
> 
> > At first, that's how I designed it. Then, I realized that the type
> > system needs to know the range type from the element type in order for
> > something like ANYRANGE to work.
> 
> That seems like a fairly bad restriction.  In a datatype with multiple
> useful sort orderings, it'd be desirable to be able to create a range
> type for each such ordering, no?  I'd be inclined to think of a range
> type as being defined by element type plus a btree opfamily.  Maybe it'd
> be okay to insist on that combination as being unique.

I couldn't find another way to make a function with a definition like:

  range(ANYELEMENT, ANYELEMENT) returns ANYRANGE

work. And it seemed worse to live without a constructor like that.
Ideas?

Also, it's not based on the btree opfamily right now. It's just based on
a user-supplied compare function. I think I could change it to store the
opfamily instead, if you think that's a better idea.

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] WIP: RangeTypes

[Tom Lane]

Jeff Davis  writes:
> On Fri, 2011-01-28 at 21:52 +, Thom Brown wrote:
> Also, if I try the same, but with a different name for the type, I get
> the same error.  Why does that restriction exist?  Can't you have
> types which happen to use the exact same subtype?

> At first, that's how I designed it. Then, I realized that the type
> system needs to know the range type from the element type in order for
> something like ANYRANGE to work.

That seems like a fairly bad restriction.  In a datatype with multiple
useful sort orderings, it'd be desirable to be able to create a range
type for each such ordering, no?  I'd be inclined to think of a range
type as being defined by element type plus a btree opfamily.  Maybe it'd
be okay to insist on that combination as being unique.

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] SPI_exec doesn't return proc context (on 9.1)

[Tom Lane]

Pavel Stehule  writes:
> I am playing with demos for PostgreSQL's Prague Developer Day and I
> found a strange behave. SPI_exec should to return to proc context. But
> it isn't true.

Yes it is.

> In following demo, I have to play with MemoryContext
> when I would to get a correct result. Is it ok?

The commented-out lines of code don't appear to have anything to do with
what you claim the problem is.  What it looks to me like you're doing is
copying the result out to the function's calling context, which is not
either of the SPI contexts established by SPI_connect (and removed by
SPI_finish).

The less crocky way to do that is to use SPI_palloc() for something that
should be allocated in the outer context.

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] WIP: RangeTypes

[Jeff Davis]

On Sat, 2011-01-29 at 11:00 -0800, David E. Wheeler wrote:
> I think I'm just revealing my ignorance of these index types and what
> they're good for. My impression has been that GIN was a better but
> less-full-featured alternative to GiST and getting better with Tom's
> recent fixes for its handling of NULLs. But, uh, obviously not.

The idea of GIN is that you store multiple entries for each tuple you
insert. So, inserting a tuple containing the document 'hello world'
would store the keys "hello" and "world" both pointing back to that
tuple. It also makes sense for arrays.

But ranges are arbitrarily long, and don't have any defined "step", so
that means an infinite number of keys. GiST works better for that.

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] Snapshots no longer build

[Magnus Hagander]

On Sat, Jan 29, 2011 at 18:33, Tom Lane  wrote:
> Magnus Hagander  writes:
>> The snapshot builds are failing with:
>> openjade:installation.sgml:1010:58:X: reference to non-existent ID 
>> "UUID-OSSP"
>> openjade:installation.sgml:1044:54:X: reference to non-existent ID "XML2"
>> openjade:/usr/local/share/sgml/docbook/dsssl/modular/html/dblink.dsl:203:1:E:
>> XRef LinkEnd to missing ID 'UUID-OSSP'
>
>> Any idea why this is happening?
>
> Bruce forgot that installation.sgml has to be buildable standalone
> ("make INSTALL" target).

Yup, that fixed it. Thanks - nagios is green and happy again.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.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] REVIEW: WIP: plpgsql - foreach in

[Pavel Stehule]

2011/1/29 Stephen Frost :
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> See also
>> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01579.php
>> which tries to draw a clear distinction between what FOR does and what
>> FOREACH does.
>
> Thanks for that, somehow I had missed that post previously.  I think I
> can get behind the idea of FOREACH being used for 'vertical'
> (multi-value in a single value) loops while FOR is used for 'horizontal'
> (multi-row).  This patch certainly needs to be improved to document
> this, in the grammar, in the code via comments, and in the actual
> documentation.  It also needs to touch any place that talks about the
> other kinds of loops to be sure that FOREACH is included and that it's
> behavior is documented accordingly.

Stephen, please, update documentation freely. Current documentation is
really minimal.

Regards

Pavel

>
>        Thanks again,
>
>                Stephen
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk1EZJEACgkQrzgMPqB3kijrawCfbvtV/2QoJ6nLvKZENcslQgz+
> do8An2Q7MvgubhLqrfbVCMiG29+RG3cp
> =RpHJ
> -END PGP SIGNATURE-
>
>

-- 
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] WIP: RangeTypes

[Jeff Davis]

On Fri, 2011-01-28 at 14:15 -0500, Chris Browne wrote:
> Mind you, timestamptzrange seems a mite *long* to me.

Right. I think we might need to compromise here an use some shorter
names. tsrange/tstzrange/numrange seem reasonable to me.

> Making sure it's consistent with int4, int8, bigint sure seems like a
> good idea.

OK, I'll change intrange to int4range, and add int8range. int2range
doesn't seem useful, though.

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] REVIEW: WIP: plpgsql - foreach in

[Stephen Frost]

* Tom Lane (t...@sss.pgh.pa.us) wrote:
> See also
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01579.php
> which tries to draw a clear distinction between what FOR does and what
> FOREACH does.

Thanks for that, somehow I had missed that post previously.  I think I
can get behind the idea of FOREACH being used for 'vertical'
(multi-value in a single value) loops while FOR is used for 'horizontal'
(multi-row).  This patch certainly needs to be improved to document
this, in the grammar, in the code via comments, and in the actual
documentation.  It also needs to touch any place that talks about the
other kinds of loops to be sure that FOREACH is included and that it's
behavior is documented accordingly.

Thanks again,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] WIP: RangeTypes

[David E. Wheeler]

On Jan 29, 2011, at 10:57 AM, Jeff Davis wrote:

> On Fri, 2011-01-28 at 10:41 -0800, David E. Wheeler wrote:
>> +1 in principal. I think we should try to avoid the user of the term
>> "period" if possible, and I see definite benefits to a simple model of
>> $typename . 'range';
> 
> Interesting, I didn't realize that PERIOD was such an undesirable type
> name.

It's not *hugely* undesirable. I just tend to think that "range" is more so.

>> Is there GIN support? GIN seems to be the preferred index type for
>> this sort of thing, no?
> 
> GiST is the natural index access method if we approach ranges as a
> spatial type. I don't quite know what you have in mind for GIN; what
> keys would you extract from the value '[1.23,4.56)' ?

I think I'm just revealing my ignorance of these index types and what they're 
good for. My impression has been that GIN was a better but less-full-featured 
alternative to GiST and getting better with Tom's recent fixes for its handling 
of NULLs. But, uh, obviously not.

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] WIP: RangeTypes

[Thom Brown]

On 29 January 2011 18:52, Jeff Davis  wrote:
> On Fri, 2011-01-28 at 21:52 +, Thom Brown wrote:
>> Also, how do you remove a range type which coincides with a system
>> range type.  For example:
>>
>> postgres=#  CREATE TYPE numrange AS RANGE (SUBTYPE=interval,
>>    SUBTYPE_CMP=interval_cmp);
>> CREATE TYPE
>> postgres=# drop type numrange;
>> ERROR:  cannot drop type numrange because it is required by the database 
>> system
>>
>> Is this because I shouldn't have been able to create this type in the
>> first place?
>
> The types are in two different schemas. It's just as though you created
> a table called pg_class.
>
> To drop the one you created, do:
>  DROP TYPE public.numrange;

*facepalm* Of course. :)  My bad.

-- 
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

-- 
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] WIP: RangeTypes

[Jeff Davis]

On Fri, 2011-01-28 at 10:41 -0800, David E. Wheeler wrote:
> +1 in principal. I think we should try to avoid the user of the term
> "period" if possible, and I see definite benefits to a simple model of
> $typename . 'range';

Interesting, I didn't realize that PERIOD was such an undesirable type
name.

> Is there GIN support? GIN seems to be the preferred index type for
> this sort of thing, no?

GiST is the natural index access method if we approach ranges as a
spatial type. I don't quite know what you have in mind for GIN; what
keys would you extract from the value '[1.23,4.56)' ?

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] WIP: RangeTypes

[Jeff Davis]

On Fri, 2011-01-28 at 21:52 +, Thom Brown wrote:
> > This is not very graceful:
> >
> > postgres=#  CREATE TYPE numrange AS RANGE (SUBTYPE=numeric,
> >   SUBTYPE_CMP=numeric_cmp);
> > ERROR:  duplicate key value violates unique constraint
> > "pg_range_rgnsubtype_index"
> > DETAIL:  Key (rngsubtype)=(1700) already exists.

You're right, that should be a much nicer error message.

> > Also, if I try the same, but with a different name for the type, I get
> > the same error.  Why does that restriction exist?  Can't you have
> > types which happen to use the exact same subtype?

At first, that's how I designed it. Then, I realized that the type
system needs to know the range type from the element type in order for
something like ANYRANGE to work.

There's a workaround though: create a domain over numeric, and then
create a range over mynumeric.

=# create domain mynumeric as numeric;
CREATE DOMAIN
=# create type numrange2 as range (subtype=numeric,
subtype_cmp=numeric_cmp);
ERROR:  duplicate key value violates unique constraint
"pg_range_rgnsubtype_index"
DETAIL:  Key (rngsubtype)=(1700) already exists.
=# create type numrange2 as range (subtype=mynumeric,
subtype_cmp=numeric_cmp);
CREATE TYPE
=# select range(1.1::mynumeric,2.2::mynumeric);
range 
--
 [ 1.1, 2.2 )
(1 row)


> Also, how do you remove a range type which coincides with a system
> range type.  For example:
> 
> postgres=#  CREATE TYPE numrange AS RANGE (SUBTYPE=interval,
>SUBTYPE_CMP=interval_cmp);
> CREATE TYPE
> postgres=# drop type numrange;
> ERROR:  cannot drop type numrange because it is required by the database 
> system
> 
> Is this because I shouldn't have been able to create this type in the
> first place?

The types are in two different schemas. It's just as though you created
a table called pg_class.

To drop the one you created, do:
  DROP TYPE public.numrange;

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

[HACKERS] SPI_exec doesn't return proc context (on 9.1)

[Pavel Stehule]

Hello

I am playing with demos for PostgreSQL's Prague Developer Day and I
found a strange behave. SPI_exec should to return to proc context. But
it isn't true. In following demo, I have to play with MemoryContext
when I would to get a correct result. Is it ok?

/*
 * contrib/citext/p2d2.c
 */
#include "postgres.h"

#include "executor/spi.h"
#include "utils/builtins.h"

#ifdef PG_MODULE_MAGIC
PG_MODULE_MAGIC;
#endif

Datum p2d2_eval(PG_FUNCTION_ARGS);

PG_FUNCTION_INFO_V1(p2d2_eval);

Datum
p2d2_eval(PG_FUNCTION_ARGS)
{
text *result = NULL;
char *query = text_to_cstring(PG_GETARG_TEXT_P(0));
int ret;
//  MemoryContext   fcectx = CurrentMemoryContext;

SPI_connect();

ret = SPI_exec(query, 0);
if (ret > 0 && SPI_tuptable != NULL)
{
TupleDesc tupdesc = SPI_tuptable->tupdesc;
SPITupleTable *tuptable = SPI_tuptable;
HeapTuple tuple = tuptable->vals[0];

if (tupdesc->natts > 1)
elog(ERROR, "Query returned more columns");

if (SPI_processed > 1)
elog(ERROR, "Query returned more rows");
else if (SPI_processed == 1)
{
elog(NOTICE, "received: \"%s\"",
SPI_getvalue(tuple, tupdesc, 1));

//  MemoryContextSwitchTo(fcectx);

result = cstring_to_text(SPI_getvalue(tuple,
tupdesc, 1));
}
}

SPI_finish();
if (result != NULL)
PG_RETURN_TEXT_P(result);
else
PG_RETURN_NULL();
}

Regards

Pavel

-- 
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] Snapshots no longer build

[Thom Brown]

On 29 January 2011 17:58, Tom Lane  wrote:
> Thom Brown  writes:
>> On 29 January 2011 11:12, Magnus Hagander  wrote:
>>> Any idea why this is happening?
>
>> I don't know what's causing that since I can see both of those IDs are
>> present, but I should also mention that the identities those linkends
>> point to should have xreflabel attributes.  At the moment, it's
>> reading: "Use the OSSP UUID library when building the Section F.44
>> module"
>
> Yeah, that is pretty icky, and Bruce introduced similar unpleasantness
> in a bunch of places.  I'm unsure that xreflabel is a good fix, though,
> because there are other places where the wording is such that a
> chapter/section number reference *is* appropriate, eg a parenthetical
> cross-reference "(see )".

Okay, I see why that's a problem.

> I think what we might need is to use xml2
> in the places where we want the xref to read as an incidental hyperlink
> rather than a cross-reference.  Comments?

Sure, that would work.

-- 
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

-- 
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] Re: [COMMITTERS] pgsql: Get rid of the global variable holding the error state

[Peter Eisentraut]

On tor, 2011-01-27 at 00:25 +0100, Jan Urbański wrote:
> _2 is only Python 2.2, but I tried: with Python 2.2 there's a whole
> lot of regression tests that fail. The last release of 2.2 is April
> 2003, maybe it's time to forget about that particular dinosaur?

I agree that we should remove the plpython_unicode_2.out expected file
since none of the other expected files support 2.2.

I would also support dropping 2.2 support at the source code level.  It
would only save a few lines of compatibility code, but we can't support
everything forever, and I think it'd be better to draw a clear line than
maintaining the current state of works-but-no-test-support.



-- 
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] REVIEW: WIP: plpgsql - foreach in

[Tom Lane]

Stephen Frost  writes:
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> You have a similar opinion like me about design this statement. But
>> there are others with strong negative opinion. For someone ARRAY ARRAY
>> should be a problem. So FOREACH is third way - more, it increase a
>> possibility for enhancing plpgsql in future.

> I look forward to hearing from the silent majority on this then.

Well, I haven't been exactly silent, but I was one of the people telling
Pavel not to use FOR in the first place.  The trouble is that we've
already overloaded FOR to within an inch of its life.  Adding yet
another potential syntax to follow FOR ... IN ... is just a bad idea,
especially since Pavel has evidently got ambitions to add yet more
nonstandard hac^H^H^Hfeatures here.

I have to agree that FOREACH is pretty ugly too, but I do *not* want to
use a syntax that can so easily be confused with the existing types of
for-loops.  We'd pay a significant price in the ability to issue syntax
error messages that were actually relevant to what the user thought he
was doing, for example.

See also
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01579.php
which tries to draw a clear distinction between what FOR does and what
FOREACH does.

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] Snapshots no longer build

[Tom Lane]

Thom Brown  writes:
> On 29 January 2011 11:12, Magnus Hagander  wrote:
>> Any idea why this is happening?

> I don't know what's causing that since I can see both of those IDs are
> present, but I should also mention that the identities those linkends
> point to should have xreflabel attributes.  At the moment, it's
> reading: "Use the OSSP UUID library when building the Section F.44
> module"

Yeah, that is pretty icky, and Bruce introduced similar unpleasantness
in a bunch of places.  I'm unsure that xreflabel is a good fix, though,
because there are other places where the wording is such that a
chapter/section number reference *is* appropriate, eg a parenthetical
cross-reference "(see )".

I think what we might need is to use xml2
in the places where we want the xref to read as an incidental hyperlink
rather than a cross-reference.  Comments?

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] Snapshots no longer build

[Tom Lane]

Magnus Hagander  writes:
> The snapshot builds are failing with:
> openjade:installation.sgml:1010:58:X: reference to non-existent ID "UUID-OSSP"
> openjade:installation.sgml:1044:54:X: reference to non-existent ID "XML2"
> openjade:/usr/local/share/sgml/docbook/dsssl/modular/html/dblink.dsl:203:1:E:
> XRef LinkEnd to missing ID 'UUID-OSSP'

> Any idea why this is happening?

Bruce forgot that installation.sgml has to be buildable standalone
("make INSTALL" target).

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] REVIEW: Determining client_encoding from client locale

[Peter Eisentraut]

On lör, 2011-01-29 at 11:50 -0500, Stephen Frost wrote:
> Greetings,
> 
> * Peter Eisentraut (pete...@gmx.net) wrote:
> > I have adjusted your old patch for the current tree, and it seems to
> > work.  I think it was just forgotten last time because the move to
> > PQconnectdbParams had to happen first.  But I'll throw it back into the
> > ring now.
> 
> Right off the bat, I don't like that you removed the references to SET
> client_encoding from the documentation, that strikes me as a good thing
> to keep, though it could go under the client_encoding varname
> documentation that you added.

I don't follow completely.  What was changed was that instead of
documenting that PGCLIENTENCODING is equivalent to SET client_encoding,
it was changed to say that PGCLIENTENCODING corresponds to the
client_encoding connection option, and the client_encoding connection
option documents that it is similar to the client_encoding server
parameter.  Maybe some wordsmithing could be applied, but I don't think
any information was actually removed.

> Also, do we really need a new set of states for this..?  I would have
> thought, just reading through the patch, that we could use the existing
> OPTION_SEND/OPTION_WAIT states..

Don't know.  Maybe Heikki could comment; he wrote that initially.

> I'll be going through the patch in more detail, testing, etc, and will
> probably go ahead and do the documentation/comment updates myself,
> unless someone cares.

Sounds good to me.



-- 
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] pg_upgrade fails for non-postgres user

[Tom Lane]

Bernd Helmle  writes:
> --On 28. Januar 2011 14:49:21 -0800 Josh Berkus  wrote:
>> The database "postgres" is
>> reasonably likely to be dropped, whereas template1 doesn't get touched
>> usually.

> This is true for a bunch of installations i know. Maybe it's worth to make 
> it a command line switch to override the default behavior, too.

You're both forgetting that the new DB is freshly initdb'd.  It is
certain to contain a postgres database.

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] REVIEW: Determining client_encoding from client locale

[Stephen Frost]

Greetings,

* Peter Eisentraut (pete...@gmx.net) wrote:
> I have adjusted your old patch for the current tree, and it seems to
> work.  I think it was just forgotten last time because the move to
> PQconnectdbParams had to happen first.  But I'll throw it back into the
> ring now.

Right off the bat, I don't like that you removed the references to SET
client_encoding from the documentation, that strikes me as a good thing
to keep, though it could go under the client_encoding varname
documentation that you added.

Also, do we really need a new set of states for this..?  I would have
thought, just reading through the patch, that we could use the existing
OPTION_SEND/OPTION_WAIT states..

I'll be going through the patch in more detail, testing, etc, and will
probably go ahead and do the documentation/comment updates myself,
unless someone cares.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] SSPI client authentication in non-Windows builds

[Magnus Hagander]

On Sat, Jan 29, 2011 at 16:22, Magnus Hagander  wrote:
> On Sat, Jan 29, 2011 at 16:21, Christian Ullrich  wrote:
>> * Magnus Hagander wrote:
>>
>>> However, i think the code path down around the error message is simply
>>> incorrect. That #ifdef spaghetti is pretty hard to parse, but it gives
>>> the wrong error message (we should say it's sspi that's not available
>>> when we have none of the two options) and/or a "duplicate case label"
>>> error, in some combinations of sspi/gssapi existing/notexisting.
>>
>>>
>>>
>>> Attached is an updated version of the patch that passes compiling on
>>> all my systems in different combinations, including msvc. Can you
>>> verify that it still works in your env? (you don't have to retest all
>>> those platforms!)
>>
>> Yes, it works fine, for md5, sspi, and gss authentication methods, tested
>> with MIT 1.4 against Windows 2008R2, PostgreSQL 8.4.4.
>
> Great, thanks!

And applied.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.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] pg_upgrade fails for non-postgres user

[Bernd Helmle]

--On 28. Januar 2011 14:49:21 -0800 Josh Berkus  wrote:


The database "postgres" is
reasonably likely to be dropped, whereas template1 doesn't get touched
usually.


This is true for a bunch of installations i know. Maybe it's worth to make 
it a command line switch to override the default behavior, too.


--
Thanks

Bernd

--
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] SSPI client authentication in non-Windows builds

[Stephen Frost]

* Magnus Hagander (mag...@hagander.net) wrote:
> They were taken out of the main packaging due to them being a PITA to
> deal with in general, IIRC.

Yes, making it very difficult for those of us who still need them. :(

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] SSPI client authentication in non-Windows builds

[Magnus Hagander]

On Sat, Jan 29, 2011 at 16:21, Christian Ullrich  wrote:
> * Magnus Hagander wrote:
>
>> However, i think the code path down around the error message is simply
>> incorrect. That #ifdef spaghetti is pretty hard to parse, but it gives
>> the wrong error message (we should say it's sspi that's not available
>> when we have none of the two options) and/or a "duplicate case label"
>> error, in some combinations of sspi/gssapi existing/notexisting.
>
>>
>>
>> Attached is an updated version of the patch that passes compiling on
>> all my systems in different combinations, including msvc. Can you
>> verify that it still works in your env? (you don't have to retest all
>> those platforms!)
>
> Yes, it works fine, for md5, sspi, and gss authentication methods, tested
> with MIT 1.4 against Windows 2008R2, PostgreSQL 8.4.4.

Great, thanks!


> For some reason, the 9.0.2 binary installer for Windows does not install the
> Kerberos/GSSAPI DLLs, so I cannot test with that version.

That's intentional - but they are not needed for SSPI operation on
windows, and in fact won't even be used by default if they're there.

They were taken out of the main packaging due to them being a PITA to
deal with in general, IIRC.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.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] SSPI client authentication in non-Windows builds

[Christian Ullrich]

* Magnus Hagander wrote:


However, i think the code path down around the error message is simply
incorrect. That #ifdef spaghetti is pretty hard to parse, but it gives
the wrong error message (we should say it's sspi that's not available
when we have none of the two options) and/or a "duplicate case label"
error, in some combinations of sspi/gssapi existing/notexisting.

>

Attached is an updated version of the patch that passes compiling on
all my systems in different combinations, including msvc. Can you
verify that it still works in your env? (you don't have to retest all
those platforms!)


Yes, it works fine, for md5, sspi, and gss authentication methods, 
tested with MIT 1.4 against Windows 2008R2, PostgreSQL 8.4.4.


For some reason, the 9.0.2 binary installer for Windows does not install 
the Kerberos/GSSAPI DLLs, so I cannot test with that version.


--
Christian

--
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] Do you have a plan to support Simplified Chinese Locale

[Andrew Dunstan]

On 01/29/2011 04:49 AM, Xiaobo Gu wrote:

Hi,
Or can you give some instructions about how to do this, thanks.





Please read the documentation (preferably before asking questions): 



The EUC_CN encoding can be used for Simplified Chineses. GB18030, which 
I understand is the Chinese national standard for software products, and 
GBK, which also supports Simplified Chinese, can be used as a client 
encoding, but not as a server encoding.


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] Spread checkpoint sync

[Robert Haas]

On Fri, Jan 28, 2011 at 12:53 AM, Greg Smith  wrote:
> Where there are still very ugly maximum latency figures here in every case,
> these periods just aren't as wide with the patch in place.

OK, committed the patch, with some additional commenting, and after
fixing the compiler warning Chris Browne noticed.

> P.S. Yes, I know I have other review work to do as well.  Starting on the
> rest of that tomorrow.

*cracks whip*

Man, this thing doesn't work at all.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
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] REVIEW: WIP: plpgsql - foreach in

[Stephen Frost]

* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> You have a similar opinion like me about design this statement. But
> there are others with strong negative opinion. For someone ARRAY ARRAY
> should be a problem. So FOREACH is third way - more, it increase a
> possibility for enhancing plpgsql in future.

I look forward to hearing from the silent majority on this then.

> the main issue was a maintainability of more complex FOR statement.

That would be a reason to not have this functionality at all, not a
reason to add confusion with a new top-level command.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] REVIEW: WIP: plpgsql - foreach in

[Pavel Stehule]

2011/1/29 Stephen Frost :
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> I don't see a problem too, but we didn't find a compromise with this
>> syntax, so I left it. It is true, so current implementation of FOR
>> stmt is really baroque and next argument is a compatibility with
>> PL/SQL. My idea is so FOR stmt will be a compatible with PL/SQL
>> original, and FOREACH can be a platform for PostgreSQL specific code.
>
> I see that as an absolutely horrible idea.  If you want that, it should
> be "PGFOR" or something, but I don't buy off on the idea that we should
> invent new top-level PG-specific keywords for PL/PgSQL because they're
> PG-specific.  I also don't see why FOR wouldn't still be as compatible
> w/ PL/SQL as it was before (except in the possible case where someone
> actually has 'ARRAY' there already, but I'm pretty sure we can convince
> ourselves that such a construct is very unlikely to appear in the wild).

you can rename it as some different than original ADA concept, if you
like. It is similar like FORALL cycle from PL/SQL. Native ADA's FOR
cycle doesn't know iteration over array.

You have a similar opinion like me about design this statement. But
there are others with strong negative opinion. For someone ARRAY ARRAY
should be a problem. So FOREACH is third way - more, it increase a
possibility for enhancing plpgsql in future.

>
> I certainly don't think we should *not* do something under FOR because
> we're worried that people might use it and then get unhappy when they
> port that code to PL/SQL.

PL/pgSQL is some like Frankenstein :) Fast, functional but sometime
strange - more stranger than origin. I don't think so it necessary to
do live harder for people who have to work with both databases.

the main issue was a maintainability of more complex FOR statement.

Pavel

>
>        Thanks,
>
>                Stephen
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk1EBDwACgkQrzgMPqB3kijDLQCcCpb15jTvU3rIdh5j9ipaqq+X
> G+wAn2WrxDkgArf5xHxt4bi8EpE0HVFP
> =Fx/8
> -END PGP SIGNATURE-
>
>

-- 
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] REVIEW: WIP: plpgsql - foreach in

[Stephen Frost]

* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> please, can you look on code that I sent last time?

I'm looking at it now and I still don't like the big set of conditionals
at the beginning which sets things up.  I do think the loop is a bit
better, but have you considered factoring out the array slicing..?  If
the built-ins don't give you what you want, write your own?  Or make
them do what you need?

Point is, that array-slicing logic has a very clear and defined purpose,
input and output, and it could be another function.

Err, oh, except you have this horribly named 'ptr' variable that's
being used across the loops.  Gah.  Alright, I'd suggest actually making
an array iterator function then, which can single-step and pull out
slices, along with a single-step iterator, and then changing the top
level to be a while() loop on that.  Notionally it's like this:

while (curr_slice_ptr =
array_slice(arr, curr_slice_ptr, slice_len, &slice, &isnull))
{
exec_assign_value(estate, ctrl_var, slice, valtype, &isnull);
rc = exec_stmts(estate, stmt->body);
/* handle return codes */
}

array_slice() could be defined to return a single value if slice_len is
1, or you could just pull out the single element if it returned a
1-element array; either way would work, imv, so long as it's commented
appropriately.

Those are my thoughts at the moment.  To be honest, I'd really like to
see this patch included in 9.1, since I can see myself using this
feature, so if you need help with some of this rework, let me know.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] Snapshots no longer build

[Thom Brown]

On 29 January 2011 11:12, Magnus Hagander  wrote:
> The snapshot builds are failing with:
>
> openjade:installation.sgml:1010:58:X: reference to non-existent ID "UUID-OSSP"
> openjade:installation.sgml:1044:54:X: reference to non-existent ID "XML2"
> openjade:/usr/local/share/sgml/docbook/dsssl/modular/html/dblink.dsl:203:1:E:
> XRef LinkEnd to missing ID 'UUID-OSSP'
> openjade:/usr/local/share/sgml/docbook/dsssl/modular/html/dblink.dsl:203:1:E:
> XRef LinkEnd to missing ID 'XML2'
> gmake[1]: *** [INSTALL.html] Error 1
> gmake[1]: *** Deleting file `INSTALL.html'
> gmake: *** [distdir] Error 2
>
>
> Looks like it's because of 159e3d86292cfec2a2828f9f69ac7a6cb1be242d.
>
>
> Any idea why this is happening?

I don't know what's causing that since I can see both of those IDs are
present, but I should also mention that the identities those linkends
point to should have xreflabel attributes.  At the moment, it's
reading: "Use the OSSP UUID library when building the Section F.44
module"

-- 
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

-- 
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] REVIEW: WIP: plpgsql - foreach in

[Stephen Frost]

* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> I don't see a problem too, but we didn't find a compromise with this
> syntax, so I left it. It is true, so current implementation of FOR
> stmt is really baroque and next argument is a compatibility with
> PL/SQL. My idea is so FOR stmt will be a compatible with PL/SQL
> original, and FOREACH can be a platform for PostgreSQL specific code.

I see that as an absolutely horrible idea.  If you want that, it should
be "PGFOR" or something, but I don't buy off on the idea that we should
invent new top-level PG-specific keywords for PL/PgSQL because they're
PG-specific.  I also don't see why FOR wouldn't still be as compatible
w/ PL/SQL as it was before (except in the possible case where someone
actually has 'ARRAY' there already, but I'm pretty sure we can convince
ourselves that such a construct is very unlikely to appear in the wild).

I certainly don't think we should *not* do something under FOR because
we're worried that people might use it and then get unhappy when they
port that code to PL/SQL.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] SSPI client authentication in non-Windows builds

[Magnus Hagander]

On Sun, Jan 23, 2011 at 16:02, Christian Ullrich  wrote:
> * Christian Ullrich wrote:
>
>> Magnus Hagander wrote:
>
>>> On Mon, Jan 3, 2011 at 14:11, Christian Ullrich
>>> wrote:
>
 This change has been tested and works correctly on FreeBSD 8.1, using
 the Kerberos and GSSAPI libraries from Heimdal 1.4. The server is
 running PostgreSQL 9.0.2 on Windows 2008.
>
>>> Does this require some certain minimum version of the kerberos
>>> libraries? Do you know if it works with just Heimdal or both Heimdal
>>> and MIT?
>
>> it works with anything but the configuration I mentioned. I will do some
>> more testing this week, but I'm limited in the number of combinations I
>> can try; some randomly chosen Linux distributions with whatever Kerberos
>> they ship and the Heimdal from the FreeBSD 8 base system instead of the
>> port (if I can get PostgreSQL to build with that) against Windows 2003
>> and 2008 is probably going to be all I can offer. Expect a report early
>> next week.
>
> This is what I tested this week. If there are any additional questions,
> please let me know.

Thanks, this is exactly the kind of testing I was hoping for - or
rather, it's a lot more extensive than I was hoping for :)

However, i think the code path down around the error message is simply
incorrect. That #ifdef spaghetti is pretty hard to parse, but it gives
the wrong error message (we should say it's sspi that's not available
when we have none of the two options) and/or a "duplicate case label"
error, in some combinations of sspi/gssapi existing/notexisting.

Attached is an updated version of the patch that passes compiling on
all my systems in different combinations, including msvc. Can you
verify that it still works in your env? (you don't have to retest all
those platforms!)

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/
diff --git a/src/interfaces/libpq/fe-auth.c b/src/interfaces/libpq/fe-auth.c
index 0d3cad0..7d2ef51 100644
--- a/src/interfaces/libpq/fe-auth.c
+++ b/src/interfaces/libpq/fe-auth.c
@@ -831,6 +831,10 @@ pg_fe_sendauth(AuthRequest areq, PGconn *conn)
 
 #if defined(ENABLE_GSS) || defined(ENABLE_SSPI)
 		case AUTH_REQ_GSS:
+#if !defined(ENABLE_SSPI)
+			/* no native SSPI, so use GSSAPI library for it */
+		case AUTH_REQ_SSPI:
+#endif
 			{
 int			r;
 
@@ -888,13 +892,14 @@ pg_fe_sendauth(AuthRequest areq, PGconn *conn)
 pgunlock_thread();
 			}
 			break;
-#else
+#else /* defined(ENABLE_GSS) || defined(ENABLE_SSPI) */
+			/* No GSSAPI *or* SSPI support */
 		case AUTH_REQ_GSS:
 		case AUTH_REQ_GSS_CONT:
 			printfPQExpBuffer(&conn->errorMessage,
 	 libpq_gettext("GSSAPI authentication not supported\n"));
 			return STATUS_ERROR;
-#endif
+#endif /* defined(ENABLE_GSS) || defined(ENABLE_SSPI) */
 
 #ifdef ENABLE_SSPI
 		case AUTH_REQ_SSPI:
@@ -914,11 +919,19 @@ pg_fe_sendauth(AuthRequest areq, PGconn *conn)
 			pgunlock_thread();
 			break;
 #else
+			/*
+			 * No SSPI support. However, if we have GSSAPI but not SSPI
+			 * support, AUTH_REQ_SSPI will have been handled in the codepath
+			 * for AUTH_REQ_GSSAPI above, so don't duplicate the case label
+			 * in that case.
+			 */
+#if !defined(ENABLE_GSS)
 		case AUTH_REQ_SSPI:
 			printfPQExpBuffer(&conn->errorMessage,
 	   libpq_gettext("SSPI authentication not supported\n"));
 			return STATUS_ERROR;
-#endif
+#endif /* !define(ENABLE_GSSAPI) */
+#endif /* ENABLE_SSPI */
 
 
 		case AUTH_REQ_CRYPT:

-- 
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] REVIEW: WIP: plpgsql - foreach in

[Pavel Stehule]

>
>> I'll try to redesign main cycle.
>
>        Thanks,
>

please, can you look on code that I sent last time?

Pavel

>                Stephen
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEUEARECAAYFAk1EAJwACgkQrzgMPqB3kig5bACdH0fm8Klh7Dq1GlICV/Z8yEd4
> KQoAlRZEeTrBkKK6TwjZrKmFDDeRfKE=
> =JPG4
> -END PGP SIGNATURE-
>
>

-- 
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] wildcard search support for pg_trgm

[Alexander Korotkov]

Hello!

New version of patch is in the attachment. Some comments was added in this
version. Likely these comments need significant correction because of my
english.
Some notes abount gin interface functions. Extract query and extract value
functions was separated, because with wildcard search these funtions no
longer do the same. New arguments was added to sql description of gin
interface functions in order to make it confom to new gin interface. See
docs of development version:
http://developer.postgresql.org/pgdocs/postgres/gin-extensibility.html.


With best regards,
Alexander Korotkov.
*** a/contrib/pg_trgm/pg_trgm.sql.in
--- b/contrib/pg_trgm/pg_trgm.sql.in
***
*** 113,118  FOR TYPE text USING gist
--- 113,120 
  AS
  OPERATOR1   % (text, text),
  OPERATOR2   <-> (text, text) FOR ORDER BY pg_catalog.float_ops,
+ OPERATOR3   ~~ (text, text),
+ OPERATOR4   ~~* (text, text),
  FUNCTION1   gtrgm_consistent (internal, text, int, oid, internal),
  FUNCTION2   gtrgm_union (bytea, internal),
  FUNCTION3   gtrgm_compress (internal),
***
*** 129,140  RETURNS internal
  AS 'MODULE_PATHNAME'
  LANGUAGE C IMMUTABLE STRICT;
  
! CREATE OR REPLACE FUNCTION gin_extract_trgm(text, internal, int2, internal, internal)
  RETURNS internal
  AS 'MODULE_PATHNAME'
  LANGUAGE C IMMUTABLE STRICT;
  
! CREATE OR REPLACE FUNCTION gin_trgm_consistent(internal, int2, text, int4, internal, internal)
  RETURNS bool
  AS 'MODULE_PATHNAME'
  LANGUAGE C IMMUTABLE STRICT;
--- 131,142 
  AS 'MODULE_PATHNAME'
  LANGUAGE C IMMUTABLE STRICT;
  
! CREATE OR REPLACE FUNCTION gin_extract_query_trgm(text, internal, int2, internal, internal, internal, internal)
  RETURNS internal
  AS 'MODULE_PATHNAME'
  LANGUAGE C IMMUTABLE STRICT;
  
! CREATE OR REPLACE FUNCTION gin_trgm_consistent(internal, int2, text, int4, internal, internal, internal, internal)
  RETURNS bool
  AS 'MODULE_PATHNAME'
  LANGUAGE C IMMUTABLE STRICT;
***
*** 144,151  CREATE OPERATOR CLASS gin_trgm_ops
  FOR TYPE text USING gin
  AS
  OPERATOR1   % (text, text),
  FUNCTION1   btint4cmp (int4, int4),
  FUNCTION2   gin_extract_trgm (text, internal),
! FUNCTION3   gin_extract_trgm (text, internal, int2, internal, internal),
! FUNCTION4   gin_trgm_consistent (internal, int2, text, int4, internal, internal),
  STORAGE int4;
--- 146,155 
  FOR TYPE text USING gin
  AS
  OPERATOR1   % (text, text),
+ OPERATOR3   ~~ (text, text),
+ OPERATOR4   ~~* (text, text),
  FUNCTION1   btint4cmp (int4, int4),
  FUNCTION2   gin_extract_trgm (text, internal),
! FUNCTION3   gin_extract_query_trgm (text, internal, int2, internal, internal, internal, internal),
! FUNCTION4   gin_trgm_consistent (internal, int2, text, int4, internal, internal, internal, internal),
  STORAGE int4;
*** a/contrib/pg_trgm/trgm.h
--- b/contrib/pg_trgm/trgm.h
***
*** 13,24 
--- 13,32 
  #define LPADDING		2
  #define RPADDING		1
  #define KEEPONLYALNUM
+ /*
+  * IGNORECASE macro means that trigrams is case-insensetive. If this macro is
+  * disabled, then ~~* operator should be excluded from operator class, because
+  * we can't handle case-insensetive wildcard search with case-sensetive
+  * trigrams.
+  */
  #define IGNORECASE
  #define DIVUNION
  
  /* operator strategy numbers */
  #define	SimilarityStrategyNumber	1
  #define	DistanceStrategyNumber		2
+ #define LikeStrategyNumber			3
+ #define ILikeStrategyNumber			4
  
  
  typedef char trgm[3];
***
*** 53,59  typedef struct
  
  /* gist */
  #define BITBYTE 8
! #define SIGLENINT  3			/* >122 => key will toast, so very slow!!! */
  #define SIGLEN	( sizeof(int)*SIGLENINT )
  
  #define SIGLENBIT (SIGLEN*BITBYTE - 1)	/* see makesign */
--- 61,67 
  
  /* gist */
  #define BITBYTE 8
! #define SIGLENINT  15			/* >122 => key will toast, so very slow!!! */
  #define SIGLEN	( sizeof(int)*SIGLENINT )
  
  #define SIGLENBIT (SIGLEN*BITBYTE - 1)	/* see makesign */
***
*** 89,94  typedef char *BITVECP;
--- 97,107 
  extern float4 trgm_limit;
  
  TRGM	   *generate_trgm(char *str, int slen);
+ TRGM	   *generate_wildcard_trgm(char *str, int slen);
  float4		cnt_sml(TRGM *trg1, TRGM *trg2);
+ booltrgm_contain(TRGM *trg1, TRGM *trg2);
+ 
+ #define ISESCAPECHAR(x) (*(x) == '\\') /* Wildcard escape character */
+ #define ISWILDCARDCHAR(x) (*(x) == '_' || *(x) == '%')  /* Wildcard meta-character */
  
  #endif /* __TRGM_H__ */
*** a/contrib/pg_trgm/trgm_gin.c
--- b/contrib/pg_trgm/trgm_gin.c
***
*** 6,11 
--- 6,12 
  #include "trgm.

Re: [HACKERS] REVIEW: WIP: plpgsql - foreach in

[Pavel Stehule]

2011/1/29 Stephen Frost :
> * Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
>> On Mon, Jan 24, 2011 at 13:05, Stephen Frost  wrote:
>> > FOR var in ARRAY array_expression ...
>> >
>> > I like that a lot more than inventing a new top-level keyword,
>>
>> AFAIR, the syntax is not good at an array literal.
>>   FOR var IN ARRAY ARRAY[1,2,5] LOOP ...
>
> I don't really see why that's "not good"?  So you have 'ARRAY' twice..
> So what?  That's better than having a new top-level FOREACH that doesn't
> have any reason to exist except to be different from FOR and to not do
> the same thing..

I don't see a problem too, but we didn't find a compromise with this
syntax, so I left it. It is true, so current implementation of FOR
stmt is really baroque and next argument is a compatibility with
PL/SQL. My idea is so FOR stmt will be a compatible with PL/SQL
original, and FOREACH can be a platform for PostgreSQL specific code.

Regards

Pavel

>
>        Thanks,
>
>                Stephen
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk1D/u8ACgkQrzgMPqB3kij2IwCfZ3W+mGc7LedBdnt9lCa0vYjk
> m6QAn0xh7r6oTs+T47k+EuwZRpU2T0X8
> =ruBa
> -END PGP SIGNATURE-
>
>

-- 
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] REVIEW: WIP: plpgsql - foreach in

[Stephen Frost]

* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> FOR keyword - please, look on thread about my proposal FOR-IN-ARRAY

I did, and I still don't agree w/ using FOREACH.

> I work with FOUND variable, because I like a consistent behave with
> FOR statement. When FOUND is true after cycle, you are sure, so there
> was a minimally one iteration.

Then the documentation around FOUND needs to be updated for FOREACH, and
there's probably other places that need to be changed too.

> > There also appears to be some extra whitespace changes that aren't
> > necessary and a number of places where you don't follow the indentation
> > conventions (eg: variable definitions in exec_stmt_foreach_a()).
> 
> I am really not sure about correct indentation of variables :(, if you
> know a correct number of spaces, please, fix it.

It's not a matter of a 'correct number of space'- make it the same as
what it is in the rest of the code...  The gist of it is to make the
variable names all line up (with maximum use of tabs at 4-spaces per
tab, of course):

int my_var;
char   *my_string;
double  my_double;

etc, etc.

> I'll try to redesign main cycle.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] REVIEW: WIP: plpgsql - foreach in

[Stephen Frost]

* Itagaki Takahiro (itagaki.takah...@gmail.com) wrote:
> On Mon, Jan 24, 2011 at 13:05, Stephen Frost  wrote:
> > FOR var in ARRAY array_expression ...
> >
> > I like that a lot more than inventing a new top-level keyword,
> 
> AFAIR, the syntax is not good at an array literal.
>   FOR var IN ARRAY ARRAY[1,2,5] LOOP ...

I don't really see why that's "not good"?  So you have 'ARRAY' twice..
So what?  That's better than having a new top-level FOREACH that doesn't
have any reason to exist except to be different from FOR and to not do
the same thing..

Thanks,

Stephen


signature.asc
Description: Digital signature

[HACKERS] Snapshots no longer build

[Magnus Hagander]

The snapshot builds are failing with:

openjade:installation.sgml:1010:58:X: reference to non-existent ID "UUID-OSSP"
openjade:installation.sgml:1044:54:X: reference to non-existent ID "XML2"
openjade:/usr/local/share/sgml/docbook/dsssl/modular/html/dblink.dsl:203:1:E:
XRef LinkEnd to missing ID 'UUID-OSSP'
openjade:/usr/local/share/sgml/docbook/dsssl/modular/html/dblink.dsl:203:1:E:
XRef LinkEnd to missing ID 'XML2'
gmake[1]: *** [INSTALL.html] Error 1
gmake[1]: *** Deleting file `INSTALL.html'
gmake: *** [distdir] Error 2


Looks like it's because of 159e3d86292cfec2a2828f9f69ac7a6cb1be242d.


Any idea why this is happening?

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.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] ALTER TYPE 3: add facility to identify further no-work cases

[Robert Haas]

On Sat, Jan 29, 2011 at 3:26 AM, Noah Misch  wrote:
> One other thing: #7 does not depend on #3,4,5,6 or any design problems raised
> thus far, so there's no need to treat it the same as that group.

Well, if you want to post an updated patch that's independent of the
rest of the series, I guess you can... but I think the chances of that
getting applied for this release are pretty much zero.  That patch
relies on some subtle changes to the contract implied by an operator
family and what looks at first blush like a lot of grotty hackery.  I
can't get very excited about spending a lot of time on that right now,
especially given the amount of difficulty we've had reaching a meeting
of the minds on cases that don't have those problems.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
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] ALTER TYPE 3: add facility to identify further no-work cases

[Robert Haas]

On Fri, Jan 28, 2011 at 4:49 PM, Noah Misch  wrote:
>> I'm not necessarily signing on to the viewpoint that
>> we should wait to do any of this work until after we refactor
>> typemods, but it does strike me that the fact that Tom and I have
>> completely different ideas of how this will interact with future
>> changes in this area probably means we need to take some more time to
>> talk about what those future enhancements might look like, rather than
>> rushing something now and maybe regretting it later.  We may not need
>> to actually do all that work before we do this, but it sounds like at
>> a minimum we need some agreement on what the design should look like.
>
> I've deferred comment due to my obvious bias, but I can't see any sense in
> blocking a change like this one on account of the exceptionally-preliminary
> discussions about enriching typmod.  Suppose, like my original design, we make
> no provision to insulate against future typmod-related changes.  The number of
> interfaces that deal in typmod are so great that the marginal effort to update
> the new ones will be irrelevant.  I still like Tom's idea of an Expr<->Expr
> interface.  I like it because it opens more opportunities now, not because it
> will eliminate some modicum of effort from an enriched-typmod implementation.

Once we add syntax to support this feature, we have to support that
syntax for an extremely long time.  We can't just remove it in the
next release and replace it with something else - pg_dump has to still
work, for example, and we have to able to reload whatever it produces.
 Adding a user-visible API that we may want to turn around and change
*next release* is just a bad idea.  If we were talking about
implementing this through some sort of hard-coded internal list of
types, it wouldn't be quite so much of an issue, but that's not where
we're at.  Moreover, I fear that injecting this into
eval_const_expressions() is adding a frammish that has no practical
utility apart from this case, but we still have to pay the overhead;
even Tom expressed some initial doubt about whether that made sense,
and I'm certainly not sold on it either.  I don't see any particular
reason why we can't resolve all of these issues, but it's going to
take more time than we have right now.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Do you have a plan to support Simplified Chinese Locale

[Xiaobo Gu]

Hi,
Or can you give some instructions about how to do this, thanks.


Xiaobo Gu

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

[Xiaobo Gu]

>
> Why are you cross-compiling? I built without any need to do that. Change the
> names of the binaries on the m mingw64/bin directory to remove the platform
> prefix, put that directory at the head of your PATH, and run a plain
> configure. Works like a charm.
I have two work computers, one is 32 bit Windows XP SP3, the other  is
64 bit Windows 7 Home basic, one is at home, the other is at work, so
to keep the same environment is more convenient for me.

I have successfully built PostgreSQL 9.0.2 according to your
suggestion on 64bit Win7 (but using an administrator user), and the
corresponding RPostgreSQL package works now, thank you all that have
helped.

Xiaobo Gu

-- 
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] ALTER TYPE 3: add facility to identify further no-work cases

[Noah Misch]

On Fri, Jan 28, 2011 at 04:49:39PM -0500, Noah Misch wrote:
> On Fri, Jan 28, 2011 at 01:52:32PM -0500, Robert Haas wrote:
> > On Wed, Jan 26, 2011 at 6:06 PM, Tom Lane  wrote:
> > > I'm not sure how important that concern is though, because it's hard to
> > > see how any such change wouldn't break existing cast implementation
> > > functions anyway. ?If the API for length-coercing cast functions
> > > changes, breaking their helper functions too hardly seems like an issue.
> > > Or are you saying you want to punt this whole proposal till after that
> > > happens? ?I had muttered something of the sort way upthread, but I
> > > didn't think anyone else thought that way.
> > 
> > I've been thinking about this patch a little bit more and I'm coming
> > around to the viewpoint that we should mark this (and the successor
> > patches in the same series) Returned with Feedback, and revisit the
> > issue for 9.2.
> 
> This is just.

One other thing: #7 does not depend on #3,4,5,6 or any design problems raised
thus far, so there's no need to treat it the same as that group.

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers