[HACKERS] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.

2011-02-17 Thread Simon Riggs
On Thu, 2011-02-17 at 00:53 +, Tom Lane wrote:

 Doesn't anybody around here pay attention to compiler warnings?

If you see one, then I accept one was there. I didn't see one, and a
full make distclean and re-compile doesn't show a compiler warning for
that either. So I guess I'm doing something wrong, on this platform:

I'm using Ubuntu 10.04 LTS, with commands for development:
./configure --enable-cassert --enable-depend --enable-debug
make -j4

The compile output has been somewhat dirty of late, with various
messages, which if nothing else indicated to me that fairly strict
warnings were enabled... though I guess not.

In file included from gram.y:12758:
scan.c: In function ‘yy_try_NUL_trans’:
scan.c:16256: warning: unused variable ‘yyg’
elog.c: In function ‘write_console’:
elog.c:1702: warning: ignoring return value of ‘write’, declared with
attribute warn_unused_result
elog.c: In function ‘write_pipe_chunks’:
elog.c:2395: warning: ignoring return value of ‘write’, declared with
attribute warn_unused_result
elog.c:2404: warning: ignoring return value of ‘write’, declared with
attribute warn_unused_result
common.c: In function ‘handle_sigint’:
common.c:247: warning: ignoring return value of ‘write’, declared with
attribute warn_unused_result
common.c:250: warning: ignoring return value of ‘write’, declared with
attribute warn_unused_result
common.c:251: warning: ignoring return value of ‘write’, declared with
attribute warn_unused_result

-- 
 Simon Riggs   http://www.2ndQuadrant.com/books/
 PostgreSQL Development, 24x7 Support, Training and Services
 


-- 
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] Fix corner case for binary upgrade: extension functions in pg_catalog.

2011-02-17 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us writes:
 Dimitri Fontaine dimi...@2ndquadrant.fr writes:
 Tom Lane p...@gwene.org writes:
 Fix corner case for binary upgrade: extension functions in pg_catalog.

 Do we only want to care about functions here?

 Yes.  Functions/aggregates are the only object type where pg_dump tries
 to suppress fetching any information at all about system-owned objects;
 it's the only case where there's so many system objects as to be worth
 the trouble.

Makes for a nice localised fix.  Thanks for explaining (again) :)

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et 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] Usability tweaks for extension commands

2011-02-17 Thread Dimitri Fontaine
Tom Lane t...@sss.pgh.pa.us writes:
 I'm just wondering whether applying that theory is leading to the
 right choices here.  In particular, the default behavior if you didn't
 say SCHEMA something would be to automatically move the extension
 into whatever random schema happens to be the front of your search_path,
 which might well not be what you intended.  Maybe it would be safer to
 not do a move on the basis of a defaulted schema selection.

Now that you say that my vote goes for ERRORing out as soon as both
schema and version are not explicitly given.

 Anyway, I think this is all 9.2 material.  I brought it up when I was
 wondering if there were a chance of making CREATE LANGUAGE translate
 into a CREATE EXTENSION operation for 9.1.  I've since given that up,
 after realizing that we are nowhere near the point where we'd be able
 to allow non-superusers to execute CREATE EXTENSION.  The permissions
 and security implications are too complicated to rush through.

I know I did not take any time to think about non-superusers and
relative security issues in my patches, but somehow though you had some
magic bullet here.  Baring that, agreed, it's not something to rush
in.

What I think we could do to solve this particular issue in 9.1 would be
for CREATE LANGUAGE to internally create an extension of the same name
and with server_version as the version.  Long term, we will want to
still have a compatibility support for CREATE LANGUAGE to still work, so
I think that's a good option here.

The version bit, you probably will say something against.  Then we could
make it '0.' || server_version (so '0.9.1' in fact).  And we solve it
fully in 9.2 where plpgsql is upgraded to '1.0'.  Unless core extensions
have the same version as the core product, unlike contrib extensions?

So in 9.1 there would be the oddity that to create the plpgsql extension
you have to issue CREATE LANGUAGE.  But as a result you can set your own
extension's control file to require plpgsql.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et 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] btree_gist (was: CommitFest progress - or lack thereof)

2011-02-17 Thread Oleg Bartunov

We need to fix inet support as Tom complained and then will commit.

Oleg
On Wed, 16 Feb 2011, Robert Haas wrote:


On Sat, Feb 12, 2011 at 8:19 AM, Robert Haas robertmh...@gmail.com wrote:

On Sat, Feb 12, 2011 at 7:47 AM, Stephen Frost sfr...@snowman.net wrote:

Oleg,

* Oleg Bartunov (o...@sai.msu.su) wrote:

what do you need for documentation ? From users point of view we add just
knn support and all examples are available in btree_gist.sql and sql
subdirectory. Contact me directly, if you have questions.


It sure seems like
http://www.postgresql.org/docs/9.0/static/btree-gist.html could be and
should be improved, in general..  If this module is really still just a
test bed for GiST, then perhaps it's not a big deal..


I agree that the documentation there could be a lot better, but I
don't think that's a commit-blocker for this patch.  However, us
reaching beta will be a commit-blocker.


Teodor, are you intending to commit this?  If so, it needs to be soon.




Regards,
Oleg
_
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: o...@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83
--
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] Fwd: [JDBC] Weird issues when reading UDT from stored function

2011-02-17 Thread rsmogura

Something like this,

Everything must be done on call, due to polymorphic signatures, this 
can be kept in short living cache, but bear in mind user can alter 
procedure in meantime.


When JDBC driver will detect if procedure call statement is created.
1. Determine procedure oid - how? procedures may have not qualified 
name. Is any function on backend that will deal with schema search path? 
You may need to pass procedure parameters or at least types? or we need 
to mirror backend code to Java?
2. Download procedure signature and parse, determine what is input and 
what is output.
3. Determine how many output parameters user registered, if 1st 
parameter is ? = exec(?, ?)
4. If only 1 parameter is output (and its UDT, pure UDT due to relkind) 
use SELECT (RESULT) as your_param_name FROM f(params) AS RESULT, if I 
remember well using () puts all in on record


Above will resolve some other problems in JDBC.

Ad 3. Problem is with 1st parameter, actually result of such procedure 
may be record, so I think I should get in our address example, when call 
? = ench(addres ?), result set like

address, address
But this is to discussion.

Postgresql has own roads, far away from support of any standard.

On Thu, 17 Feb 2011 13:14:46 +1300, Oliver Jowett wrote:

On 17/02/11 04:23, Tom Lane wrote:

Florian Pflug f...@phlo.org writes:
Hm, I've browsed through the code and it seems that the current 
behaviour

was implemented on purpose.


Yes, it's 100% intentional.  The idea is to allow function authors 
to
use OUT-parameter notation (in particular, the convention of 
assigning

to a named variable to set the result) without forcing them into the
overhead of returning a record when all they want is to return a 
scalar.

So a single OUT parameter is *supposed* to work just like a function
that does returns whatever without any OUT parameters.

Even if you think this was a bad choice, which I don't, it's far too
late to change it.


Any suggestions about how the JDBC driver can express the query to 
get

the behavior that it wants? Specifically, the driver wants to call a
particular function with N OUT or INOUT parameters (and maybe some 
other

IN parameters too) and get a resultset with N columns back.

The current approach is to say SELECT * FROM f(params) AS RESULT 
which
works in all cases *except* for the case where there is exactly one 
OUT

parameter and it has a record/UDT type.

Oliver



--
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] Fwd: [JDBC] Weird issues when reading UDT from stored function

2011-02-17 Thread Florian Pflug
On Feb17, 2011, at 01:14 , Oliver Jowett wrote:
 Any suggestions about how the JDBC driver can express the query to get
 the behavior that it wants? Specifically, the driver wants to call a
 particular function with N OUT or INOUT parameters (and maybe some other
 IN parameters too) and get a resultset with N columns back.

There's no sane way to do that, I fear. You could of course look up the
function definition in the catalog before actually calling it, but with
overloading and polymorphic types finding the right pg_proc entry seems
awfully complex.

Your best option is probably to just document this caveat...

best regards,
Florian Pflug



-- 
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] Fwd: [JDBC] Weird issues when reading UDT from stored function

2011-02-17 Thread Florian Pflug
On Feb17, 2011, at 10:30 , rsmogura wrote:
 When JDBC driver will detect if procedure call statement is created.
 1. Determine procedure oid - how? procedures may have not qualified name. Is 
 any function on backend that will deal with schema search path? You may need 
 to pass procedure parameters or at least types? or we need to mirror backend 
 code to Java?

That change of getting this correct without help from the backend is exactly 
zero. (Hint: You need to consider overloaded functions and implicit casts of 
parameters...)

best regards,
Florian Pflug


-- 
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] Fwd: [JDBC] Weird issues when reading UDT from stored function

2011-02-17 Thread Pavel Stehule
2011/2/17 Florian Pflug f...@phlo.org:
 On Feb17, 2011, at 10:30 , rsmogura wrote:
 When JDBC driver will detect if procedure call statement is created.
 1. Determine procedure oid - how? procedures may have not qualified name. Is 
 any function on backend that will deal with schema search path? You may need 
 to pass procedure parameters or at least types? or we need to mirror backend 
 code to Java?

 That change of getting this correct without help from the backend is exactly 
 zero. (Hint: You need to consider overloaded functions and implicit casts of 
 parameters...)


There is only one way - implementation of CALL statement. Any
emulation on JDBC level is just way to hell. Now, we have to say -
PostgreSQL doesn't support a CALL statement, support only functions -
and everybody has to use a different pattern than in other databases.
Any emulation on JDBC means, it will be slowly, it will be
unpredictable.

Regards

Pavel Stehule


 best regards,
 Florian Pflug


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


-- 
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] Debian readline/libedit breakage

2011-02-17 Thread Andrea Suisani

On 02/10/2011 11:34 PM, Joshua D. Drake wrote:

Hello,

Per:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109

It seems we may have a problem to consider. As far as I know, we are the
only major platform that supports libedit but our default is readline.
Unfortunately readline is not compatible with OpenSSL (apparently?)
licensing.

This seems that it may be a problem for us considering the pre-package
builds we do.

What does everyone think? Should we work on getting libedit up to snuff?

JD


on lwn.net there's a nice summary about this debate
you can read it at (*):

http://lwn.net/SubscriberLink/428111/36b6b26832f4309d/

Andrea


--
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] Fwd: [JDBC] Weird issues when reading UDT from stored function

2011-02-17 Thread rsmogura

Yes new node should be created and added for 8.x and 9.x releases...

On Thu, 17 Feb 2011 10:53:19 +0100, Pavel Stehule wrote:

2011/2/17 Florian Pflug f...@phlo.org:

On Feb17, 2011, at 10:30 , rsmogura wrote:
When JDBC driver will detect if procedure call statement is 
created.
1. Determine procedure oid - how? procedures may have not qualified 
name. Is any function on backend that will deal with schema search 
path? You may need to pass procedure parameters or at least types? or 
we need to mirror backend code to Java?


That change of getting this correct without help from the backend is 
exactly zero. (Hint: You need to consider overloaded functions and 
implicit casts of parameters...)




There is only one way - implementation of CALL statement. Any
emulation on JDBC level is just way to hell. Now, we have to say -
PostgreSQL doesn't support a CALL statement, support only functions -
and everybody has to use a different pattern than in other databases.
Any emulation on JDBC means, it will be slowly, it will be
unpredictable.

Regards

Pavel Stehule



best regards,
Florian Pflug


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




--
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] Fwd: [JDBC] Weird issues when reading UDT from stored function

2011-02-17 Thread Oliver Jowett

Lukas Eder wrote:

The result set meta data correctly state that there are 6 OUT columns. 
But only the first 2 are actually fetched (because of a nested UDT)...


The data mangling was just a plpgsql syntactic issue, wasn't it?

Oliver

--
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] Fwd: [JDBC] Weird issues when reading UDT from stored function

2011-02-17 Thread rsmogura
Maybe change in backend to treat complex types marked in relation as 
COMPLEX in same way as scalar values is solution, actually I don't know. 
This can be determined by GUC variable so every one can be happy :)


On Thu, 17 Feb 2011 23:08:13 +1300, Oliver Jowett wrote:

Lukas Eder wrote:

The result set meta data correctly state that there are 6 OUT 
columns. But only the first 2 are actually fetched (because of a 
nested UDT)...


The data mangling was just a plpgsql syntactic issue, wasn't it?

Oliver



--
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] Fwd: [JDBC] Weird issues when reading UDT from stored function

2011-02-17 Thread Oliver Jowett

Florian Pflug wrote:

On Feb17, 2011, at 01:14 , Oliver Jowett wrote:

Any suggestions about how the JDBC driver can express the query to get
the behavior that it wants? Specifically, the driver wants to call a
particular function with N OUT or INOUT parameters (and maybe some other
IN parameters too) and get a resultset with N columns back.


There's no sane way to do that, I fear. You could of course look up the
function definition in the catalog before actually calling it, but with
overloading and polymorphic types finding the right pg_proc entry seems
awfully complex.

Your best option is probably to just document this caveat...


Well, the JDBC driver does know how many OUT parameters there are before 
execution happens, so it could theoretically do something different for 
1 OUT vs. many OUT parameters.


The problem is that currently the translation of the JDBC { call } 
escape happens early on, well before we know which parameters are OUT 
parameters. Moving that translation later is, at best, tricky, so I was 
hoping there was one query form that would handle all cases.


Oliver

--
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] Fwd: [JDBC] Weird issues when reading UDT from stored function

2011-02-17 Thread Pavel Stehule
2011/2/17 rsmogura rsmog...@softperience.eu:
 Yes new node should be created and added for 8.x and 9.x releases...

what node?

Pavel


 On Thu, 17 Feb 2011 10:53:19 +0100, Pavel Stehule wrote:

 2011/2/17 Florian Pflug f...@phlo.org:

 On Feb17, 2011, at 10:30 , rsmogura wrote:

 When JDBC driver will detect if procedure call statement is created.
 1. Determine procedure oid - how? procedures may have not qualified
 name. Is any function on backend that will deal with schema search path? 
 You
 may need to pass procedure parameters or at least types? or we need to
 mirror backend code to Java?

 That change of getting this correct without help from the backend is
 exactly zero. (Hint: You need to consider overloaded functions and implicit
 casts of parameters...)


 There is only one way - implementation of CALL statement. Any
 emulation on JDBC level is just way to hell. Now, we have to say -
 PostgreSQL doesn't support a CALL statement, support only functions -
 and everybody has to use a different pattern than in other databases.
 Any emulation on JDBC means, it will be slowly, it will be
 unpredictable.

 Regards

 Pavel Stehule


 best regards,
 Florian Pflug


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




-- 
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] Fwd: [JDBC] Weird issues when reading UDT from stored function

2011-02-17 Thread rsmogura
Yes, but driver checks number of declared out parameters and number of 
resulted parameters (even check types of those), to prevent programming 
errors.


On Thu, 17 Feb 2011 23:15:07 +1300, Oliver Jowett wrote:

Florian Pflug wrote:

On Feb17, 2011, at 01:14 , Oliver Jowett wrote:
Any suggestions about how the JDBC driver can express the query to 
get
the behavior that it wants? Specifically, the driver wants to call 
a
particular function with N OUT or INOUT parameters (and maybe some 
other

IN parameters too) and get a resultset with N columns back.
There's no sane way to do that, I fear. You could of course look up 
the
function definition in the catalog before actually calling it, but 
with
overloading and polymorphic types finding the right pg_proc entry 
seems

awfully complex.
Your best option is probably to just document this caveat...


Well, the JDBC driver does know how many OUT parameters there are
before execution happens, so it could theoretically do something
different for 1 OUT vs. many OUT parameters.

The problem is that currently the translation of the JDBC { call }
escape happens early on, well before we know which parameters are OUT
parameters. Moving that translation later is, at best, tricky, so I
was hoping there was one query form that would handle all cases.

Oliver



--
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] tsearch Parser Hacking

2011-02-17 Thread Jesper Krogh
On 16 Feb 2011, at 23:22, David E. Wheeler da...@kineticode.com wrote:

 On Feb 14, 2011, at 11:44 PM, Oleg Bartunov wrote:
 
 IMO, sooner or later we need to trash that code and replace it with
 something a bit more modification-friendly.
 
 We thought about configurable parser, but AFAIR, we didn't get any support 
 for this at that time.
 
 What would it take to change the requirement such that *any* SQL function 
 could be a parser, not only C functions? Maybe require that they turn a 
 nested array of tokens? That way I could just write a function in PL/Perl 
 quite easily.

I had just the same thought in mind. But so far I systematically substitute _ 
and a few other characters to ł which doesn't get interpreted as blanks.  But 
more direct control would be appreciated 

Jesper
-- 
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] Debian readline/libedit breakage

2011-02-17 Thread Magnus Hagander
On Thu, Feb 17, 2011 at 05:23, Joshua D. Drake j...@commandprompt.com wrote:
 On Wed, 2011-02-16 at 22:53 -0500, Bruce Momjian wrote:
 Stephen Frost wrote:
 -- Start of PGP signed section.
  * Greg Stark (gsst...@mit.edu) wrote:
   Well for what it's worth we want to support both. At least the project
   philosophy has been that commercial derivatives are expected and
   acceptable so things like EDB's products, or Greenplums, or for that
   matter Pokertracker's all include other proprietary source that of
   course has restrictive licenses (OpenSSL-type-licensed except even
   *more* restrictive).
 
  This is a bit backwards, I think..  What you're suggesting is that, some
  day, we might want community/BSD-licensed PG to link against
  commercially licensed products from EDB for basic functionality (eg:
  encryption)?
 
  I agree that we want to reduce and eliminate, to the extent possible,
  our dependence on GPL or OpenSSL-type-licensed libraries.  It's
  unfortunate that there isn't a good non-GPL option for libreadline, but
  I'm not sure what EDB or anyone else would expect the PG community to
  do regarding that.  Should PG remove support for libreadline?  Should
  the PG community make libedit a good BSD-licensed alternative to
  libreadline?  Neither of those really make sense to me.

 What are our click-installers doing now?

 Probably readline but does it matter? We distribute the source to the
 click installers.

Actually, we don't. We used to, but we don't at this point.

-- 
 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] Debian readline/libedit breakage

2011-02-17 Thread Dave Page
On Thu, Feb 17, 2011 at 10:36 AM, Magnus Hagander mag...@hagander.net wrote:
 On Thu, Feb 17, 2011 at 05:23, Joshua D. Drake j...@commandprompt.com wrote:
 On Wed, 2011-02-16 at 22:53 -0500, Bruce Momjian wrote:
 Stephen Frost wrote:
 -- Start of PGP signed section.
  * Greg Stark (gsst...@mit.edu) wrote:
   Well for what it's worth we want to support both. At least the project
   philosophy has been that commercial derivatives are expected and
   acceptable so things like EDB's products, or Greenplums, or for that
   matter Pokertracker's all include other proprietary source that of
   course has restrictive licenses (OpenSSL-type-licensed except even
   *more* restrictive).
 
  This is a bit backwards, I think..  What you're suggesting is that, some
  day, we might want community/BSD-licensed PG to link against
  commercially licensed products from EDB for basic functionality (eg:
  encryption)?
 
  I agree that we want to reduce and eliminate, to the extent possible,
  our dependence on GPL or OpenSSL-type-licensed libraries.  It's
  unfortunate that there isn't a good non-GPL option for libreadline, but
  I'm not sure what EDB or anyone else would expect the PG community to
  do regarding that.  Should PG remove support for libreadline?  Should
  the PG community make libedit a good BSD-licensed alternative to
  libreadline?  Neither of those really make sense to me.

 What are our click-installers doing now?

 Probably readline but does it matter? We distribute the source to the
 click installers.

 Actually, we don't. We used to, but we don't at this point.

Depends on your definition of distribute (and what part you are
specifically referring to). There's no tarball, but the installer
sources are on git.postgresql.org.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: 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] Fwd: [JDBC] Weird issues when reading UDT from stored function

2011-02-17 Thread Oliver Jowett
On 17/02/11 23:18, rsmogura wrote:
 Yes, but driver checks number of declared out parameters and number of
 resulted parameters (even check types of those), to prevent programming
 errors.

And..?

Oliver

-- 
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] Debian readline/libedit breakage

2011-02-17 Thread Greg Stark
On Thu, Feb 17, 2011 at 4:50 AM, Jason Earl je...@notengoamigos.org wrote:
 This will be a significant advantage for
        further free software development, and some projects will decide
        to make software free in order to use these libraries.

You've misread this paragraph. Postgres is already free (except for
the OpenSSL restrictions). Even
by these people's definitions you don't need to use the GPL to be
free.

-- 
greg

-- 
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] btree_gist (was: CommitFest progress - or lack thereof)

2011-02-17 Thread Robert Haas
2011/2/17 Oleg Bartunov o...@sai.msu.su:
 We need to fix inet support as Tom complained and then will commit.

I think those are two separate issues.

-- 
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] Fwd: [JDBC] Weird issues when reading UDT from stored function

2011-02-17 Thread rsmogura

On Fri, 18 Feb 2011 00:06:22 +1300, Oliver Jowett wrote:

On 17/02/11 23:18, rsmogura wrote:
Yes, but driver checks number of declared out parameters and number 
of
resulted parameters (even check types of those), to prevent 
programming

errors.


And..?

Oliver


And it will throw exception when result will income. If you will remove 
this then you will lose check against programming errors, when number of 
expected parameters is different that number of actual parameters. Bear 
in mind that you will get result set of 6 columns, but only 1 is 
expected. I think you can't determine what should be returned and how to 
fix result without 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] sepgsql contrib module

2011-02-17 Thread Robert Haas
On Thu, Feb 17, 2011 at 3:56 AM, Kohei Kaigai kohei.kai...@eu.nec.com wrote:
 The attached patch removes rules to build a policy package for regression
 test and modifies documentation part to introduce steps to run the test.

Committed.  Incidentally, on my Ubuntu system:

$ find /usr/share/selinux -name '*ake*'
/usr/share/selinux/default/include/Makefile
/usr/share/selinux/ubuntu/include/Makefile
/usr/share/selinux/mls/include/Makefile

Not sure which of these would be the right one to use.

-- 
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] Debian readline/libedit breakage

2011-02-17 Thread Greg Stark
On Thu, Feb 17, 2011 at 3:39 AM, Stephen Frost sfr...@snowman.net wrote:
 * Greg Stark (gsst...@mit.edu) wrote:
 Well for what it's worth we want to support both. At least the project
 philosophy has been that commercial derivatives are expected and
 acceptable so things like EDB's products, or Greenplums, or for that
 matter Pokertracker's all include other proprietary source that of
 course has restrictive licenses (OpenSSL-type-licensed except even
 *more* restrictive).

 This is a bit backwards, I think..  What you're suggesting is that, some
 day, we might want community/BSD-licensed PG to link against
 commercially licensed products from EDB for basic functionality (eg:
 encryption)?


No. Firstly we're not talking about linking -- linking is just a
technical step and the law is much fuzzier and general than that. When
you build a binary it's a derivative work of all the components that
went into building that binary whether they were linked in or not.
This includes the macros in the header files that were used, the
parser code from bison, etc.

Secondly I'm not talking about how what software is in the community
licensed PG. We have always said in the past that we want Postgres to
be usable by other people to embed in their commercially licensed
software and that means that the license has to allow not just
redistributing Postgres but redistributing it under more restrictive
licenses.



-- 
greg

-- 
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] Fwd: [JDBC] Weird issues when reading UDT from stored function

2011-02-17 Thread Oliver Jowett
On 18/02/11 00:37, rsmogura wrote:
 On Fri, 18 Feb 2011 00:06:22 +1300, Oliver Jowett wrote:
 On 17/02/11 23:18, rsmogura wrote:
 Yes, but driver checks number of declared out parameters and number of
 resulted parameters (even check types of those), to prevent programming
 errors.

 And..?

 Oliver
 
 And it will throw exception when result will income. If you will remove
 this then you will lose check against programming errors, when number of
 expected parameters is different that number of actual parameters. Bear
 in mind that you will get result set of 6 columns, but only 1 is
 expected. I think you can't determine what should be returned and how to
 fix result without signature.

You've completely missed the point. I am not suggesting we change those
checks at all. I am suggesting we change how the JDBC driver translates
call escapes to queries so that for N OUT parameters, we always get
exactly N result columns, without depending on the datatypes of the
parameters in any way.

Oliver

-- 
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] Debian readline/libedit breakage

2011-02-17 Thread Magnus Hagander
On Thu, Feb 17, 2011 at 11:49, Dave Page dp...@pgadmin.org wrote:
 On Thu, Feb 17, 2011 at 10:36 AM, Magnus Hagander mag...@hagander.net wrote:
 On Thu, Feb 17, 2011 at 05:23, Joshua D. Drake j...@commandprompt.com 
 wrote:
 On Wed, 2011-02-16 at 22:53 -0500, Bruce Momjian wrote:
 Stephen Frost wrote:
 -- Start of PGP signed section.
  * Greg Stark (gsst...@mit.edu) wrote:
   Well for what it's worth we want to support both. At least the project
   philosophy has been that commercial derivatives are expected and
   acceptable so things like EDB's products, or Greenplums, or for that
   matter Pokertracker's all include other proprietary source that of
   course has restrictive licenses (OpenSSL-type-licensed except even
   *more* restrictive).
 
  This is a bit backwards, I think..  What you're suggesting is that, some
  day, we might want community/BSD-licensed PG to link against
  commercially licensed products from EDB for basic functionality (eg:
  encryption)?
 
  I agree that we want to reduce and eliminate, to the extent possible,
  our dependence on GPL or OpenSSL-type-licensed libraries.  It's
  unfortunate that there isn't a good non-GPL option for libreadline, but
  I'm not sure what EDB or anyone else would expect the PG community to
  do regarding that.  Should PG remove support for libreadline?  Should
  the PG community make libedit a good BSD-licensed alternative to
  libreadline?  Neither of those really make sense to me.

 What are our click-installers doing now?

 Probably readline but does it matter? We distribute the source to the
 click installers.

 Actually, we don't. We used to, but we don't at this point.

 Depends on your definition of distribute (and what part you are
 specifically referring to). There's no tarball, but the installer
 sources are on git.postgresql.org.

Oh, my bad - they're back. I was referring to our discussion a couple
of weeks back (I think), when you said that was too much work :-P

My apologies.


-- 
 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] Debian readline/libedit breakage

2011-02-17 Thread Dave Page
On Thu, Feb 17, 2011 at 11:45 AM, Magnus Hagander mag...@hagander.net wrote:
 On Thu, Feb 17, 2011 at 11:49, Dave Page dp...@pgadmin.org wrote:
 Depends on your definition of distribute (and what part you are
 specifically referring to). There's no tarball, but the installer
 sources are on git.postgresql.org.

 Oh, my bad - they're back. I was referring to our discussion a couple
 of weeks back (I think), when you said that was too much work :-P

For the record, it wasn't keeping the PG installer source code public
that was too much work, it was cleaning out some of the unrelated code
from other installers.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: 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] Fwd: [JDBC] Weird issues when reading UDT from stored function

2011-02-17 Thread rsmogura

On Fri, 18 Feb 2011 00:44:07 +1300, Oliver Jowett wrote:

On 18/02/11 00:37, rsmogura wrote:

On Fri, 18 Feb 2011 00:06:22 +1300, Oliver Jowett wrote:

On 17/02/11 23:18, rsmogura wrote:
Yes, but driver checks number of declared out parameters and 
number of
resulted parameters (even check types of those), to prevent 
programming

errors.


And..?

Oliver


And it will throw exception when result will income. If you will 
remove
this then you will lose check against programming errors, when 
number of
expected parameters is different that number of actual parameters. 
Bear

in mind that you will get result set of 6 columns, but only 1 is
expected. I think you can't determine what should be returned and 
how to

fix result without signature.


You've completely missed the point. I am not suggesting we change 
those
checks at all. I am suggesting we change how the JDBC driver 
translates

call escapes to queries so that for N OUT parameters, we always get
exactly N result columns, without depending on the datatypes of the
parameters in any way.

Oliver


May You provide example select for this, and check behaviour with below 
procedure, too.


CREATE OR REPLACE FUNCTION p_enhance_address3(OUT address 
u_address_type, OUT i1 integer)

  RETURNS record AS
$BODY$
BEGIN
SELECT t_author.address
INTO address
FROM t_author
WHERE first_name = 'George';
i1 = 12;
END;
$BODY$
  LANGUAGE plpgsql

--
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] Fwd: [JDBC] Weird issues when reading UDT from stored function

2011-02-17 Thread Oliver Jowett
On 18/02/11 00:52, rsmogura wrote:
 On Fri, 18 Feb 2011 00:44:07 +1300, Oliver Jowett wrote:
 On 18/02/11 00:37, rsmogura wrote:
 On Fri, 18 Feb 2011 00:06:22 +1300, Oliver Jowett wrote:
 On 17/02/11 23:18, rsmogura wrote:
 Yes, but driver checks number of declared out parameters and number of
 resulted parameters (even check types of those), to prevent
 programming
 errors.

 And..?

 Oliver

 And it will throw exception when result will income. If you will remove
 this then you will lose check against programming errors, when number of
 expected parameters is different that number of actual parameters. Bear
 in mind that you will get result set of 6 columns, but only 1 is
 expected. I think you can't determine what should be returned and how to
 fix result without signature.

 You've completely missed the point. I am not suggesting we change those
 checks at all. I am suggesting we change how the JDBC driver translates
 call escapes to queries so that for N OUT parameters, we always get
 exactly N result columns, without depending on the datatypes of the
 parameters in any way.

 Oliver
 
 May You provide example select for this, and check behaviour with below
 procedure, too.
 
 CREATE OR REPLACE FUNCTION p_enhance_address3(OUT address
 u_address_type, OUT i1 integer)
   RETURNS record AS
 $BODY$
 BEGIN
 SELECT t_author.address
 INTO address
 FROM t_author
 WHERE first_name = 'George';
 i1 = 12;
 END;
 $BODY$
   LANGUAGE plpgsql

Oh god I'm going round and round in circles repeating myself!

There are two problems.

The first problem is a plpgsql problem in that particular function. It's
broken regardless of how you call it. Here's how to fix it:

 testdb=# CREATE FUNCTION p_enhance_address4 (address OUT u_address_type) AS 
 $$ BEGIN address := (SELECT t_author.address FROM t_author WHERE first_name = 
 'George'); END; $$ LANGUAGE plpgsql;
 CREATE FUNCTION
 testdb=# SELECT * FROM p_enhance_address4();
  street |  zip   |   city| country |   since| code 
 ++---+-++--
  (Parliament Hill,77) | NW31A9 | Hampstead | England | 1980-01-01 | 
 (1 row)

The second problem is that the JDBC driver always generates calls in the
SELECT * FROM ... form, but this does not work correctly for
one-OUT-parameter-that-is-a-UDT, as seen in the example immediately
above. Here's how to do the call for that particular case:

 testdb=# SELECT p_enhance_address4();
 p_enhance_address4 
 ---
  ((Parliament Hill,77),NW31A9,Hampstead,England,1980-01-01,)
 (1 row)

The challenge is that the bare SELECT form doesn't work for multiple OUT
parameters, so the driver has to select one form or the other based on
the number of OUT parameters.

Any questions? (I'm sure there will be questions. Sigh.)

Oliver

-- 
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] Fwd: [JDBC] Weird issues when reading UDT from stored function

2011-02-17 Thread Florian Pflug
On Feb17, 2011, at 11:15 , Oliver Jowett wrote:
 Florian Pflug wrote:
 On Feb17, 2011, at 01:14 , Oliver Jowett wrote:
 Any suggestions about how the JDBC driver can express the query to get
 the behavior that it wants? Specifically, the driver wants to call a
 particular function with N OUT or INOUT parameters (and maybe some other
 IN parameters too) and get a resultset with N columns back.
 There's no sane way to do that, I fear. You could of course look up the
 function definition in the catalog before actually calling it, but with
 overloading and polymorphic types finding the right pg_proc entry seems
 awfully complex.
 Your best option is probably to just document this caveat...
 
 Well, the JDBC driver does know how many OUT parameters there are before 
 execution happens, so it could theoretically do something different for 1 OUT 
 vs. many OUT parameters.

Right, I had forgotten that JDBC must be told about OUT parameter with 
registerOutputType()

 The problem is that currently the translation of the JDBC { call } escape 
 happens early on, well before we know which parameters are OUT parameters. 
 Moving that translation later is, at best, tricky, so I was hoping there was 
 one query form that would handle all cases.

Hm, now I'm confused. Even leaving the single-OUT-parameter problem aside, the 
JDBC statement {call f(?,?)} either translates to
  SELECT * FROM f($1)
or
  SELECT * FROM f($1, $2)
depending on whether one of the parameter is OUT. Without knowing the number of 
output parameters, how do you distinguish these two cases?

best regards,
Florian Pflug


-- 
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] Fwd: [JDBC] Weird issues when reading UDT from stored function

2011-02-17 Thread Oliver Jowett
On 18/02/11 01:08, Florian Pflug wrote:

 Well, the JDBC driver does know how many OUT parameters there are before 
 execution happens, so it could theoretically do something different for 1 
 OUT vs. many OUT parameters.
 
 Right, I had forgotten that JDBC must be told about OUT parameter with 
 registerOutputType()
 
 The problem is that currently the translation of the JDBC { call } escape 
 happens early on, well before we know which parameters are OUT parameters. 
 Moving that translation later is, at best, tricky, so I was hoping there was 
 one query form that would handle all cases.
 
 Hm, now I'm confused. Even leaving the single-OUT-parameter problem aside, 
 the JDBC statement {call f(?,?)} either translates to
   SELECT * FROM f($1)
 or
   SELECT * FROM f($1, $2)
 depending on whether one of the parameter is OUT. Without knowing the number 
 of output parameters, how do you distinguish these two cases?

Currently it always includes *all* parameters in the call, regardless of
the number of OUT parameters (as mentioned, it doesn't even know how
many OUT parameters there are at that point). As we discover OUT
parameters, we bind void types to them, and the server does the rest of
the heavy lifting. Something roughly equivalent to this:

 testdb=# PREPARE s1(void) AS SELECT * FROM p_enhance_address4($1); -- 
 function has no IN parameters, one OUT parameter
 PREPARE
 testdb=# EXECUTE s1(null);
  street |  zip   |   city| country |   since| code 
 ++---+-++--
  (Parliament Hill,77) | NW31A9 | Hampstead | England | 1980-01-01 | 
 (1 row)

Oliver

-- 
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] Fwd: [JDBC] Weird issues when reading UDT from stored function

2011-02-17 Thread rsmogura

snip
testdb=# CREATE FUNCTION p_enhance_address4 (address OUT 
u_address_type) AS $$ BEGIN address := (SELECT t_author.address FROM 
t_author WHERE first_name = 'George'); END; $$ LANGUAGE plpgsql;

CREATE FUNCTION
testdb=# SELECT * FROM p_enhance_address4();
 street |  zip   |   city| country |   since
| code


++---+-++--
 (Parliament Hill,77) | NW31A9 | Hampstead | England | 1980-01-01 
|

(1 row)


The second problem is that the JDBC driver always generates calls in 
the

SELECT * FROM ... form, but this does not work correctly for
one-OUT-parameter-that-is-a-UDT, as seen in the example immediately
above. Here's how to do the call for that particular case:


testdb=# SELECT p_enhance_address4();
p_enhance_address4
---
 ((Parliament Hill,77),NW31A9,Hampstead,England,1980-01-01,)
(1 row)


The challenge is that the bare SELECT form doesn't work for multiple 
OUT
parameters, so the driver has to select one form or the other based 
on

the number of OUT parameters.

Any questions? (I'm sure there will be questions. Sigh.)

Oliver


I don't want to blame or anything similar, any idea is good, as any 
effort as well, but if user will register one output parameter, but 
procedure will have two will it be possible to check this? I'm little 
lost in this nested records. If there will be no such check I suggest to 
configure this by connection parameter, because in any way UDTs aren't 
such popular, user should have choice to decide I want better checks, 
or I need this! Everything is on my side.



--
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] Fix for Index Advisor related hooks

2011-02-17 Thread Gurjeet Singh
On Wed, Feb 16, 2011 at 6:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:

 Gurjeet Singh singh.gurj...@gmail.com writes:
  On Wed, Feb 16, 2011 at 10:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
  The only reason you'd need that code is if you were trying to construct
  a fake Relation structure, which seems unnecessary and undesirable.

  The planner requires IndexOptInfo, and for the planner to choose the
  hypothetical index we need to fill in the fwdsortop, revsortop, opfamily
 and
  opcintype, and this is the information that IndexAdvisor populates using
  IndexSupportInitialize() (at least until c0b5fac7 changed the function
  signature.

 Yeah, and the set of stuff you need in IndexOptInfo changed again last
 week; see collations.  Direct access to IndexSupportInitialize is even
 less useful today than it was a week ago.  This stuff has changed many
 times before, and it will change again in the future, and exporting a
 private function that has an unrelated purpose is not going to insulate
 you from needing to deal with that.


I guess you are right.



  What would be the best way to build an IndexOptInfo for a plain BTREE
 index
  for different data types?

 Fetch the values you need and stuff 'em in the struct.  Don't expect
 relcache to do it for you.  The only reason relcache is involved in the
 current workflow is that we try to cache the information across queries
 in order to save on planner startup time ... but I don't think that that
 concern is nearly as pressing for something like Index Advisor.  You'll
 have enough to do tracking changes in IndexOptInfo, you don't need to
 have to deal with refactorings inside relcache as well.


I also wish to make Index Advisor faster by not having to lookup this info
every time a new query comes in and that's why I was trying to use the guts
of IndexSupportInitialize() where it does the caching. If Index Advisor went
on its own then we'll be implementing caching of opfamily and opcintype etc
in the contrib/ code. And I am pretty sure we can't do it any better than
what Postgres is currently doing in terms of managing that cache and
possibly invalidating it when some relevant DDL happens.

Would it be possible to somehow expose that cache managed by
LookupOpclassInfo()? I see the comments above it note that it does not
handle invalidation since there's no need for it because currently one
cannot ALTER an opclass. But I do not wish to be revisiting this problem
when that changes. IOW, when ALTER for opclass is implemented,
LookupOpclassInfo would be changed to handle invalidation and I wish to
leverage that; it might mean change in function signature, but I guess Index
Advisor will have to live with that.

Thanks,
-- 
gurjeet.singh
@ EnterpriseDB - The Enterprise Postgres Company
http://www.EnterpriseDB.com

singh.gurjeet@{ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet

Mail sent from my BlackLaptop device


Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

2011-02-17 Thread Peter Eisentraut
On fre, 2011-02-11 at 14:19 -0500, Tom Lane wrote:
  But now, let's make it harder.  I've found a grave bug in 1.1, which
  causes the PG backend to segfault.  Easy fix, good thing, so now I
  release 1.2:
 
 Unless the bug is such that you have to change the installation script
 file, there is no reason to bump the version number at all.  These
 version numbers apply to the install SQL script, not the
 underlying .so.

I think this shows that the installation script version number should be
independent of the overall package's version number.  You just change
the installation script version number when it is required that the
script be run as part of an upgrade, otherwise you leave it.  This is
very similar to the version numbers of shared libraries, which also
change independently of the overall package.

So perhaps installation script version numbers should just be integers
starting at 1, period.

Otherwise I fear people will try to make the numbers match their package
version number, which will either create stupid installation script
sequences or stupid package version numbers, like those peculiar fellows
who change the shared library version number in accordance with their
package version number.

This would of course also simplify many other aspects about which
version numbers to allow and how to compare them.



-- 
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 two dashes in extension load files

2011-02-17 Thread Peter Eisentraut
On tis, 2011-02-15 at 15:32 -0500, Tom Lane wrote:
 I can't claim close familiarity with Debian's conventions in this
 matter, but I do know about RPM's, and I'm uneager to duplicate that
 silliness.  Magic conversion of dots to underscores (sometimes),
 complete inability to determine which part of the package filename is
 which without external knowledge, etc.

FYI, the system in Debian is that '_' separate package name and version,
and '_' is not allowed in package name or version.  I guess since we
want to allow both '_' and '-' in package names, we can't really do that
or anything similar.



-- 
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: Fix blatantly uninitialized variable in recent commit.

2011-02-17 Thread Peter Geoghegan
On 17 February 2011 08:30, Simon Riggs si...@2ndquadrant.com wrote:
 In file included from gram.y:12758:
 scan.c: In function ‘yy_try_NUL_trans’:
 scan.c:16256: warning: unused variable ‘yyg’

Lots of people have reported that one. It's been around since August
of last year, if not earlier.

-- 
Regards,
Peter Geoghegan

-- 
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: Fix blatantly uninitialized variable in recent commit.

2011-02-17 Thread Simon Riggs
On Thu, 2011-02-17 at 14:37 +, Peter Geoghegan wrote:
 On 17 February 2011 08:30, Simon Riggs si...@2ndquadrant.com wrote:
  In file included from gram.y:12758:
  scan.c: In function ‘yy_try_NUL_trans’:
  scan.c:16256: warning: unused variable ‘yyg’
 
 Lots of people have reported that one. It's been around since August
 of last year, if not earlier.

Yeh. I wasn't reporting it as an error, just showing the absence of a
warning for an uninitialized variable in the case shown.

What I should have said was: please share any tips for improving error
checking.

-- 
 Simon Riggs   http://www.2ndQuadrant.com/books/
 PostgreSQL Development, 24x7 Support, Training and Services
 


-- 
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: Fix blatantly uninitialized variable in recent commit.

2011-02-17 Thread Robert Haas
On Thu, Feb 17, 2011 at 9:50 AM, Simon Riggs si...@2ndquadrant.com wrote:
 On Thu, 2011-02-17 at 14:37 +, Peter Geoghegan wrote:
 On 17 February 2011 08:30, Simon Riggs si...@2ndquadrant.com wrote:
  In file included from gram.y:12758:
  scan.c: In function ‘yy_try_NUL_trans’:
  scan.c:16256: warning: unused variable ‘yyg’

 Lots of people have reported that one. It's been around since August
 of last year, if not earlier.

 Yeh. I wasn't reporting it as an error, just showing the absence of a
 warning for an uninitialized variable in the case shown.

 What I should have said was: please share any tips for improving error
 checking.

On MacOS X and Fedora, I put COPT=-Werror in src/Makefile.custom.
(There's a -Wno-error in the rule that compiles scan.c, so it all
works.)  But I can't do that on my Ubuntu machine because of those
stupid warnings about write().

-- 
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] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.

2011-02-17 Thread Tom Lane
Simon Riggs si...@2ndquadrant.com writes:
 On Thu, 2011-02-17 at 00:53 +, Tom Lane wrote:
 Doesn't anybody around here pay attention to compiler warnings?

 If you see one, then I accept one was there. I didn't see one, and a
 full make distclean and re-compile doesn't show a compiler warning for
 that either. So I guess I'm doing something wrong, on this platform:

 I'm using Ubuntu 10.04 LTS, with commands for development:
 ./configure --enable-cassert --enable-depend --enable-debug
 make -j4

Hmm ... the only plausible reason I can think of for gcc not showing
that warning would be building with -O0 (which disables the flow graph
computations needed to detect uses of uninitialized values).  Your
configure command doesn't betray any such thing, but maybe you've got
some CFLAGS overrides you're not showing us?

I usually find that -O1 is the best compromise setting for development
builds.  It enables uninitialized-variable warnings but doesn't produce
code that's completely unfriendly to gdb.  (Sometimes I do recompile a
specific file at -O0 if it's making no sense during single-stepping.)

 The compile output has been somewhat dirty of late, with various
 messages, which if nothing else indicated to me that fairly strict
 warnings were enabled... though I guess not.

In my builds, the only warning anywhere is the unused variable in
gram.y, which is a bison bug that we can't do anything about (except
complain to the bison folk, which I've done).  It might be worth trying
to clean up those warn_unused_result things, if other people are seeing
those.

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] btree_gist (was: CommitFest progress - or lack thereof)

2011-02-17 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes:
 2011/2/17 Oleg Bartunov o...@sai.msu.su:
 We need to fix inet support as Tom complained and then will commit.

 I think those are two separate issues.

Yeah ... also, fixing the inet problem looked to me like it'd probably
be a major compatibility break (change in on-disk index contents).
Not something to rush into at the end of a development cycle.

In any case, I was pointing to that as a reason that btree_gist wasn't
ready to be in core.  It has nothing to do with KNN-ifying the module.
I would like to see that happen before 9.1, else KNN will go out with
not very many actual use-cases supported.

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] Debian readline/libedit breakage

2011-02-17 Thread Bruce Momjian
Dave Page wrote:
 On Thu, Feb 17, 2011 at 11:45 AM, Magnus Hagander mag...@hagander.net wrote:
  On Thu, Feb 17, 2011 at 11:49, Dave Page dp...@pgadmin.org wrote:
  Depends on your definition of distribute (and what part you are
  specifically referring to). There's no tarball, but the installer
  sources are on git.postgresql.org.
 
  Oh, my bad - they're back. I was referring to our discussion a couple
  of weeks back (I think), when you said that was too much work :-P
 
 For the record, it wasn't keeping the PG installer source code public
 that was too much work, it was cleaning out some of the unrelated code
 from other installers.

Well, we are going down a slippery slope if we think the click-through
installers are OK to use readline and distribute because we supply the
source for the installers --- that then requires anyone using the
binaries (or libraries) in those installers to also supply the source
code, e.g. GPL.  :-(  I am not saying they have to, but falling back to
the oh we give source code for the click-through installers is not a
position we can fall back on without affecting our users.

Also, I think part of the problem for Debian is that they distribute
readline and Postgres because they are the operating system vendor.  I
don't think the use the OS library if already present interpretation
of the GPL really thought about that case.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
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] Debian readline/libedit breakage

2011-02-17 Thread Bruce Momjian
Stephen Frost wrote:
-- Start of PGP signed section.
 * Bruce Momjian (br...@momjian.us) wrote:
  Joshua D. Drake wrote:
   Probably readline but does it matter? We distribute the source to the
   click installers.
  
  Well, there is what the community is risking, and there is what the
  packagers are risking.  Ideally we would make the job easier for the
  packagers too, though we don't have to.
 
 I'm really mystified by this.  If the source is available for the
 installers, what's the risk that you're worried about..?  For the
 community or the packagers?

I just posted on this.  The risk is to people using the packages --- the
packages themselves include the source as an option, so they are fine,
but everyone using those packages would also be required to distribute
source, which is a restriction we have avoided in the past.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
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] Debian readline/libedit breakage

2011-02-17 Thread Stephen Frost
* Bruce Momjian (br...@momjian.us) wrote:
 Well, we are going down a slippery slope if we think the click-through
 installers are OK to use readline and distribute because we supply the
 source for the installers --- that then requires anyone using the
 binaries (or libraries) in those installers to also supply the source
 code, e.g. GPL.

If they build binaries which include the GPL'd readline, then there's a
(potential) issue, sure.  I'm not sure what system you're looking at,
but readline isn't linked in by libpq today and I can't imagine it ever
being linked to it.

If they're using the binaries which the community provides, I really
don't believe there's any issue.  It's possible someone would ask for
the source code for that psql binary, but that shouldn't/wouldn't be
hard for them to produce for the community psql.

If they're building their own binaries of psql which they've modified
*and* have linked in with readline, then they've put themselves into a
position where FSF or someone could complain.  I'd recommend they not do
that, so as to avoid the issue.

 :-(  I am not saying they have to, but falling back to
 the oh we give source code for the click-through installers is not a
 position we can fall back on without affecting our users.

I really don't follow the logic here.  Are you suggesting that people
take psql and *embed* it into their own binaries?

If there's really that much concern over it, presumably the installers
could be built w/o readline support.

That'd probably be more comfortable for me anyway, since then psql on
Windows would behave like every other Windows app. ;) (j/k..)

 Also, I think part of the problem for Debian is that they distribute
 readline and Postgres because they are the operating system vendor.  I
 don't think the use the OS library if already present interpretation
 of the GPL really thought about that case.

I don't think this really plays into this whole thing at all, but my
understanding is that Debian intentionally doesn't use that clause
because it's vague.

Thanks,

Stephen


signature.asc
Description: Digital signature


Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.

2011-02-17 Thread Simon Riggs
On Thu, 2011-02-17 at 10:09 -0500, Tom Lane wrote:
 Simon Riggs si...@2ndquadrant.com writes:
  On Thu, 2011-02-17 at 00:53 +, Tom Lane wrote:
  Doesn't anybody around here pay attention to compiler warnings?
 
  If you see one, then I accept one was there. I didn't see one, and a
  full make distclean and re-compile doesn't show a compiler warning for
  that either. So I guess I'm doing something wrong, on this platform:
 
  I'm using Ubuntu 10.04 LTS, with commands for development:
  ./configure --enable-cassert --enable-depend --enable-debug
  make -j4
 
 Hmm ... the only plausible reason I can think of for gcc not showing
 that warning would be building with -O0 (which disables the flow graph
 computations needed to detect uses of uninitialized values).  Your
 configure command doesn't betray any such thing, but maybe you've got
 some CFLAGS overrides you're not showing us?

No, nothing set

 I usually find that -O1 is the best compromise setting for development
 builds.  It enables uninitialized-variable warnings but doesn't produce
 code that's completely unfriendly to gdb.  (Sometimes I do recompile a
 specific file at -O0 if it's making no sense during single-stepping.)
 
  The compile output has been somewhat dirty of late, with various
  messages, which if nothing else indicated to me that fairly strict
  warnings were enabled... though I guess not.
 
 In my builds, the only warning anywhere is the unused variable in
 gram.y, which is a bison bug that we can't do anything about (except
 complain to the bison folk, which I've done).  It might be worth trying
 to clean up those warn_unused_result things, if other people are seeing
 those.

Thanks, will investigate.

-- 
 Simon Riggs   http://www.2ndQuadrant.com/books/
 PostgreSQL Development, 24x7 Support, Training and Services
 


-- 
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] Debian readline/libedit breakage

2011-02-17 Thread Stephen Frost
* Bruce Momjian (br...@momjian.us) wrote:
 I just posted on this.  The risk is to people using the packages --- the
 packages themselves include the source as an option, so they are fine,
 but everyone using those packages would also be required to distribute
 source, which is a restriction we have avoided in the past.

I think you may want to reread the GPL on this.  They're not actually
required to distribute source *with* the binaries (hell, Debian
doesn't..) as long as they are willing to produce it if asked.  And
that's the source for the binaries which actually depend on the GPL'd
code, eg, the community-built psql binary that you're talking about
here..  They don't have to provide source for everything on the CD or
something (again, Debian has a non-free section also..).

Thanks,

Stephen


signature.asc
Description: Digital signature


Re: [HACKERS] Add support for logging the current role

2011-02-17 Thread Robert Haas
On Wed, Feb 16, 2011 at 9:52 PM, Stephen Frost sfr...@snowman.net wrote:
 * Robert Haas (robertmh...@gmail.com) wrote:
 Ah, so it does.  Sounds like you win.  Have we a patch implementing
 the sounds-like-its-agreed change, then?

 Patch attached, rebased to current master.

Ugg, wait a minute.  This not only adds %U; it also changes the
behavior of %u, which I don't think we've agreed on.  Also, emitting
'none' when not SET ROLE has been done is pretty ugly.  I'm back to
thinking we need to push this out to 9.2 and take more time to think
about this.

-- 
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] Add support for logging the current role

2011-02-17 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes:
 Ugg, wait a minute.  This not only adds %U; it also changes the
 behavior of %u, which I don't think we've agreed on.  Also, emitting
 'none' when not SET ROLE has been done is pretty ugly.  I'm back to
 thinking we need to push this out to 9.2 and take more time to think
 about this.

Yeah, I thought what was supposed to be emitted was the value of
current_user, not SQL's weird definition of what SET ROLE means.

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] Add support for logging the current role

2011-02-17 Thread Stephen Frost
* Robert Haas (robertmh...@gmail.com) wrote:
 Ugg, wait a minute.  This not only adds %U; it also changes the
 behavior of %u, which I don't think we've agreed on.  Also, emitting
 'none' when not SET ROLE has been done is pretty ugly.  I'm back to
 thinking we need to push this out to 9.2 and take more time to think
 about this.

As I explained in various commit logs and, as I recall, when I first
posted about it, the behavior change for %u could only come about when
someone used 'SET SESSION AUTHORIZATION', which requires superuser
privileges.  It makes more sense to me for 'user_name' to be equivilant
to 'SESSION USER', but it's really not that big a deal either way.

Guess I had foolishly thought that people were alright with it by lack
of any comments on it. :(  Does anyone else want to chime in on this?

I actually came across that problem because the documentation was poor
regarding exactly what that column meant.  If we actually want it to be
the name that the user first used to authenticate to the system with,
then let's update the documentation accordingly and we can remove those
changes.

Thanks,

Stephen


signature.asc
Description: Digital signature


Re: [HACKERS] Add support for logging the current role

2011-02-17 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote:
 Robert Haas robertmh...@gmail.com writes:
  Ugg, wait a minute.  This not only adds %U; it also changes the
  behavior of %u, which I don't think we've agreed on.  Also, emitting
  'none' when not SET ROLE has been done is pretty ugly.  I'm back to
  thinking we need to push this out to 9.2 and take more time to think
  about this.
 
 Yeah, I thought what was supposed to be emitted was the value of
 current_user, not SQL's weird definition of what SET ROLE means.

current_user uses GetUserNameFromId() and goes through the cache lookups
to get there.  I was using what show_role() returns (which is also what
'show role;' returns).  I'd be happy to make it emit an empty string
when 'none' is returned though.

Thanks,

Stephen


signature.asc
Description: Digital signature


Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

2011-02-17 Thread Tom Lane
Peter Eisentraut pete...@gmx.net writes:
 On fre, 2011-02-11 at 14:19 -0500, Tom Lane wrote:
 Unless the bug is such that you have to change the installation script
 file, there is no reason to bump the version number at all.  These
 version numbers apply to the install SQL script, not the
 underlying .so.

 I think this shows that the installation script version number should be
 independent of the overall package's version number.  You just change
 the installation script version number when it is required that the
 script be run as part of an upgrade, otherwise you leave it.  This is
 very similar to the version numbers of shared libraries, which also
 change independently of the overall package.

 So perhaps installation script version numbers should just be integers
 starting at 1, period.

Well, people are certainly free to use them that way, but I'm not sure
there's much to be gained by forcing it.  What I'd sort of assumed we
would do with the contrib scripts is major.minor, where a bump in the
minor number is for a compatible upgrade (ie, run ALTER EXTENSION UPDATE
and you're good) while a bump in the major number would be for
incompatible changes.

 Otherwise I fear people will try to make the numbers match their package
 version number, which will either create stupid installation script
 sequences or stupid package version numbers, like those peculiar fellows
 who change the shared library version number in accordance with their
 package version number.

I hear you, but even if we did restrict script versions to integers,
people would still be tempted to sync them with some part of their
package version number, and then they'd still get burnt.  I think this
is more a matter for documentation of how-you-should-use-this than
something we can try to force programmatically.

 This would of course also simplify many other aspects about which
 version numbers to allow and how to compare them.

It would enable comparisons, but we don't seem to need those after all.
I don't think it really solves any problems in filename parsing, unless
you'd like to disallow digits in extension names ...

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] Add support for logging the current role

2011-02-17 Thread Tom Lane
Stephen Frost sfr...@snowman.net writes:
 * Tom Lane (t...@sss.pgh.pa.us) wrote:
 Yeah, I thought what was supposed to be emitted was the value of
 current_user, not SQL's weird definition of what SET ROLE means.

 current_user uses GetUserNameFromId() and goes through the cache lookups
 to get there.  I was using what show_role() returns (which is also what
 'show role;' returns).  I'd be happy to make it emit an empty string
 when 'none' is returned though.

Well, that just doesn't seem useful to me in the real world.  If I were
using this, I would expect it to emit a real user name that matches the
currently applied permissions checking.  All the time.  show role does
what it does because the SQL standard says so, not because anybody
outside the standards committee thinks that's a sane definition.

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] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.

2011-02-17 Thread Kevin Grittner
Tom Lane t...@sss.pgh.pa.us wrote:
 
 It might be worth trying to clean up those warn_unused_result
 things, if other people are seeing those.
 
In `make world` I'm seeing:
 
scan.c: In function *yy_try_NUL_trans*:
scan.c:16256: warning: unused variable *yyg*
--
elog.c: In function *write_console*:
elog.c:1708: warning: ignoring return value of *write*, declared
with attribute warn_unused_result
elog.c: In function *write_pipe_chunks*:
elog.c:2401: warning: ignoring return value of *write*, declared
with attribute warn_unused_result
elog.c:2410: warning: ignoring return value of *write*, declared
with attribute warn_unused_result
--
common.c: In function *handle_sigint*:
common.c:247: warning: ignoring return value of *write*, declared
with attribute warn_unused_result
common.c:250: warning: ignoring return value of *write*, declared
with attribute warn_unused_result
common.c:251: warning: ignoring return value of *write*, declared
with attribute warn_unused_result
--
option.c: In function *parseCommandLine*:
option.c:92: warning: ignoring return value of *getcwd*, declared
with attribute warn_unused_result
option.c: In function *get_pkglibdir*:
option.c:336: warning: ignoring return value of *fgets*, declared
with attribute warn_unused_result
 
Example of a compile line showing a warning:
 
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wformat-security
-fno-strict-aliasing -fwrapv -g -I../../../../src/include
-D_GNU_SOURCE -I/usr/include/libxml2   -c -o elog.o elog.c -MMD -MP
-MF .deps/elog.Po
 
-Kevin

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


Re: [HACKERS] Add support for logging the current role

2011-02-17 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote:
 Well, that just doesn't seem useful to me in the real world.  If I were
 using this, I would expect it to emit a real user name that matches the
 currently applied permissions checking.  All the time.

I wouldn't have ever thought to use %U w/o %u, to be honest.  Unless I'm
missing something though, this change would just be emitting what
show_session_authorization() returns when show_role() returns 'none'.
That's certainly fine by me.

 show role does
 what it does because the SQL standard says so, not because anybody
 outside the standards committee thinks that's a sane definition.

Guess it actually makes some sense to me.

Thanks,

Stephen


signature.asc
Description: Digital signature


Re: [HACKERS] Debian readline/libedit breakage

2011-02-17 Thread Bruce Momjian
Stephen Frost wrote:
-- Start of PGP signed section.
 * Bruce Momjian (br...@momjian.us) wrote:
  Well, we are going down a slippery slope if we think the click-through
  installers are OK to use readline and distribute because we supply the
  source for the installers --- that then requires anyone using the
  binaries (or libraries) in those installers to also supply the source
  code, e.g. GPL.
 
 If they build binaries which include the GPL'd readline, then there's a
 (potential) issue, sure.  I'm not sure what system you're looking at,
 but readline isn't linked in by libpq today and I can't imagine it ever
 being linked to it.

It is true that readline is not linked to libpq, but that muddies the
waters.  Notice that Dave said the source to Postgres is distributed,
not that psql source is distributed, meaning he didn't make the
distinction between psql and the complete source, and most users aren't
going to understand that distinction.

 If they're using the binaries which the community provides, I really
 don't believe there's any issue.  It's possible someone would ask for
 the source code for that psql binary, but that shouldn't/wouldn't be
 hard for them to produce for the community psql.
 
 If they're building their own binaries of psql which they've modified
 *and* have linked in with readline, then they've put themselves into a
 position where FSF or someone could complain.  I'd recommend they not do
 that, so as to avoid the issue.

True.  I just hate to have anything in a packaged distribution that has
any GPL requirement, even if it is a binary that no one can link to.
Call me paranoid, but I see it as marketing confusion for us.

  :-(  I am not saying they have to, but falling back to
  the oh we give source code for the click-through installers is not a
  position we can fall back on without affecting our users.
 
 I really don't follow the logic here.  Are you suggesting that people
 take psql and *embed* it into their own binaries?
 
 If there's really that much concern over it, presumably the installers
 could be built w/o readline support.
 
 That'd probably be more comfortable for me anyway, since then psql on
 Windows would behave like every other Windows app. ;) (j/k..)

psql used to use the native Windows line editing ability --- has that
changed?

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
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] Debian readline/libedit breakage

2011-02-17 Thread Bruce Momjian
Stephen Frost wrote:
-- Start of PGP signed section.
 * Bruce Momjian (br...@momjian.us) wrote:
  I just posted on this.  The risk is to people using the packages --- the
  packages themselves include the source as an option, so they are fine,
  but everyone using those packages would also be required to distribute
  source, which is a restriction we have avoided in the past.
 
 I think you may want to reread the GPL on this.  They're not actually
 required to distribute source *with* the binaries (hell, Debian
 doesn't..) as long as they are willing to produce it if asked.  And
 that's the source for the binaries which actually depend on the GPL'd
 code, eg, the community-built psql binary that you're talking about
 here..  They don't have to provide source for everything on the CD or
 something (again, Debian has a non-free section also..).

Yes, I understand very well the source does not have to be with the
binary.  I am trying to avoid that non-BSD-licensed section in our
installers.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
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: Fix blatantly uninitialized variable in recent commit.

2011-02-17 Thread Tom Lane
Kevin Grittner kevin.gritt...@wicourts.gov writes:
 Tom Lane t...@sss.pgh.pa.us wrote:
 It might be worth trying to clean up those warn_unused_result
 things, if other people are seeing those.

 elog.c: In function *write_console*:
 elog.c:1708: warning: ignoring return value of *write*, declared
 with attribute warn_unused_result
 elog.c: In function *write_pipe_chunks*:
 elog.c:2401: warning: ignoring return value of *write*, declared
 with attribute warn_unused_result
 elog.c:2410: warning: ignoring return value of *write*, declared
 with attribute warn_unused_result
 --
 common.c: In function *handle_sigint*:
 common.c:247: warning: ignoring return value of *write*, declared
 with attribute warn_unused_result
 common.c:250: warning: ignoring return value of *write*, declared
 with attribute warn_unused_result
 common.c:251: warning: ignoring return value of *write*, declared
 with attribute warn_unused_result

In at least some of these cases, I think ignoring the write() result
is intentional, because there's really nothing useful we can do about
it if it fails (oh, you wish we'd log a failure to write to the log?).
Would you check whether just casting the function result to (void)
shuts it up?

 option.c: In function *parseCommandLine*:
 option.c:92: warning: ignoring return value of *getcwd*, declared
 with attribute warn_unused_result
 option.c: In function *get_pkglibdir*:
 option.c:336: warning: ignoring return value of *fgets*, declared
 with attribute warn_unused_result

These look like they probably are genuine bugs, or if not bugs at least
the kind of sloppy coding the warning is meant to catch.

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] Debian readline/libedit breakage

2011-02-17 Thread Stephen Frost
* Bruce Momjian (br...@momjian.us) wrote:
 psql used to use the native Windows line editing ability --- has that
 changed?

*that* I couldn't tell you..

Thanks,

Stephen


signature.asc
Description: Digital signature


Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.

2011-02-17 Thread Kevin Grittner
Tom Lane t...@sss.pgh.pa.us wrote:
 
 Would you check whether just casting the function result to (void)
 shuts it up?
 
Casting the result to (void) didn't change the warning.  It shut up
when I declared a local variable and assigned the value to it (which
was then never used).
 
-Kevin

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


Re: [HACKERS] Debian readline/libedit breakage

2011-02-17 Thread Andrew Dunstan



On 02/17/2011 11:22 AM, Bruce Momjian wrote:

psql used to use the native Windows line editing ability --- has that
changed?



When did it? Ad what native windows line editing ability are you 
referring to?


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] Debian readline/libedit breakage

2011-02-17 Thread Bruce Momjian
Andrew Dunstan wrote:
 
 
 On 02/17/2011 11:22 AM, Bruce Momjian wrote:
  psql used to use the native Windows line editing ability --- has that
  changed?
 
 
 When did it? Ad what native windows line editing ability are you 
 referring to?

There is native Windows editing like arrows, etc and history, though the
history is not kept between sessions.  If windows is now using readline,
then odds are we are shipping libreadline to make that happen, and we
are then linking using a supplied GPL library (and we don't have the
OS-installed exception).  I hope I am wrong.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
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] Add support for logging the current role

2011-02-17 Thread Stephen Frost
* Robert Haas (robertmh...@gmail.com) wrote:
 Ugg, wait a minute.  This not only adds %U; it also changes the
 behavior of %u, which I don't think we've agreed on.  Also, emitting
 'none' when not SET ROLE has been done is pretty ugly.  I'm back to
 thinking we need to push this out to 9.2 and take more time to think
 about this.

%u, user_name, etc changes reverted.

%U now always returns the role currently being used for permissions
checks, by using show_session_authorization() when show_role() returns
'none'.  Ditto for CSV updates.

git log below, re-based patch attached.  All regression tests passed,
tested with log_line_prefix and csvlog also, all looks good to me.

Robert, if you say this has to be punted to 9.2 again, I'm giving up. ;)

Thanks,

Stephen
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
***
*** 3562,3568  local0.*/var/log/postgresql
  /row
  row
   entryliteral%u/literal/entry
!  entryUser name/entry
   entryyes/entry
  /row
  row
--- 3562,3579 
  /row
  row
   entryliteral%u/literal/entry
!  entryAuthenticated user name, the user name that the user used
!  to authenticate to productnamePostgreSQL/productname with.
!  entryyes/entry
! /row
! row
!  entryliteral%U/literal/entry
!  entryCurrent role being used for permissions checking, can be
!  set with commandSET ROLE/ or commandSET SESSION
!  AUTHORIZATION/ (only allowed for superusers);
!  Note: Log messages from inside literalSECURITY DEFINER/
!  functions will show the calling role, not the effective role
!  inside the literalSECURITY DEFINER/ function/entry
   entryyes/entry
  /row
  row
***
*** 3790,3795  FROM pg_stat_activity;
--- 3801,3807 
  with these columns:
  timestamp with milliseconds,
  user name,
+ current role name,
  database name,
  process ID,
  client host:port number,
***
*** 3820,3825  CREATE TABLE postgres_log
--- 3832,3838 
  (
log_time timestamp(3) with time zone,
user_name text,
+   curr_role text,
database_name text,
process_id integer,
connection_from text,
*** a/src/backend/commands/variable.c
--- b/src/backend/commands/variable.c
***
*** 847,852  assign_session_authorization(const char *value, bool doit, GucSource source)
--- 847,857 
  	return result;
  }
  
+ /*
+  * function to return the stored session username, needed because we
+  * can't do catalog lookups when possibly being called after an error,
+  * eg: from elog.c or part of GUC handling.
+  */
  const char *
  show_session_authorization(void)
  {
***
*** 972,977  assign_role(const char *value, bool doit, GucSource source)
--- 977,987 
  	return result;
  }
  
+ /*
+  * function to return the stored role username, needed because we
+  * can't do catalog lookups when possibly being called after an error,
+  * eg: from elog.c or part of GUC handling.
+  */
  const char *
  show_role(void)
  {
*** a/src/backend/utils/error/elog.c
--- b/src/backend/utils/error/elog.c
***
*** 65,70 
--- 65,71 
  
  #include access/transam.h
  #include access/xact.h
+ #include commands/variable.h
  #include libpq/libpq.h
  #include libpq/pqformat.h
  #include mb/pg_wchar.h
***
*** 1777,1782  log_line_prefix(StringInfo buf, ErrorData *edata)
--- 1778,1795 
  	int			format_len;
  	int			i;
  
+ 	/* gather current session and role names */
+ 	const char *session_auth = show_session_authorization();
+ 	const char *role_auth = show_role();
+ 
+ 	/* what we'll actually log as current role, based on if
+ 	 * a set role has been done or not */
+ 	char	   *curr_role = role_auth;
+ 
+ 	/* if show_role() returns 'none', then we log the session user instead */
+ 	if (strcmp(role_auth,none) == 0)
+ 		curr_role = session_auth;
+ 
  	/*
  	 * This is one of the few places where we'd rather not inherit a static
  	 * variable's value from the postmaster.  But since we will, reset it when
***
*** 1832,1837  log_line_prefix(StringInfo buf, ErrorData *edata)
--- 1845,1853 
  	appendStringInfoString(buf, username);
  }
  break;
+ 			case 'U':
+ appendStringInfoString(buf, curr_role);
+ break;
  			case 'd':
  if (MyProcPort)
  {
***
*** 1967,1972  write_csvlog(ErrorData *edata)
--- 1983,2000 
  	/* has counter been reset in current process? */
  	static int	log_my_pid = 0;
  
+ 	/* pull the session authorization */
+ 	const char *session_auth = show_session_authorization();
+ 	const char *role_auth = show_role();
+ 
+ 	/* what we'll actually log as current role, based 

Re: [HACKERS] Debian readline/libedit breakage

2011-02-17 Thread Andrew Dunstan



On 02/17/2011 11:44 AM, Bruce Momjian wrote:

Andrew Dunstan wrote:


On 02/17/2011 11:22 AM, Bruce Momjian wrote:

psql used to use the native Windows line editing ability --- has that
changed?


When did it? Ad what native windows line editing ability are you
referring to?

There is native Windows editing like arrows, etc and history, though the
history is not kept between sessions.  If windows is now using readline,
then odds are we are shipping libreadline to make that happen, and we
are then linking using a supplied GPL library (and we don't have the
OS-installed exception).  I hope I am wrong.



Readline has always been disabled on Windows builds AFAIK. Just look at 
the buildfarm traces. Here's an example from 
http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=frogmouthdt=2011-02-17%2015%3A30%3A03stg=configure


   configure: WARNING: *** Readline does not work on MinGW --- disabling


It's not used in MSVC either, IIRC.

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] Debian readline/libedit breakage

2011-02-17 Thread Bruce Momjian
Andrew Dunstan wrote:
 
 
 On 02/17/2011 11:44 AM, Bruce Momjian wrote:
  Andrew Dunstan wrote:
 
  On 02/17/2011 11:22 AM, Bruce Momjian wrote:
  psql used to use the native Windows line editing ability --- has that
  changed?
 
  When did it? Ad what native windows line editing ability are you
  referring to?
  There is native Windows editing like arrows, etc and history, though the
  history is not kept between sessions.  If windows is now using readline,
  then odds are we are shipping libreadline to make that happen, and we
  are then linking using a supplied GPL library (and we don't have the
  OS-installed exception).  I hope I am wrong.
 
 
 Readline has always been disabled on Windows builds AFAIK. Just look at 
 the buildfarm traces. Here's an example from 
 http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=frogmouthdt=2011-02-17%2015%3A30%3A03stg=configure
 
 configure: WARNING: *** Readline does not work on MinGW --- disabling
 
 
 It's not used in MSVC either, IIRC.


OK, I was only responding to Stephen Frost who said psql did not behave
like other Windows apps.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
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] sepgsql contrib module

2011-02-17 Thread Kohei Kaigai
The attached patch removes rules to build a policy package for regression
test and modifies documentation part to introduce steps to run the test.

Thanks,
--
NEC Europe Ltd, Global Competence Center
KaiGai Kohei kohei.kai...@eu.nec.com


 -Original Message-
 From: Kohei Kaigai
 Sent: 15 February 2011 18:27
 To: 'Robert Haas'; Tom Lane
 Cc: Andrew Dunstan; Stephen Frost; KaiGai Kohei; PgHacker
 Subject: RE: [HACKERS] sepgsql contrib module
 
 
 
  -Original Message-
  From: Robert Haas [mailto:robertmh...@gmail.com]
  Sent: 15 February 2011 16:52
  To: Tom Lane
  Cc: Andrew Dunstan; Kohei Kaigai; Stephen Frost; KaiGai Kohei; PgHacker
  Subject: Re: [HACKERS] sepgsql contrib module
 
  On Tue, Feb 15, 2011 at 11:41 AM, Tom Lane t...@sss.pgh.pa.us wrote:
   Robert Haas robertmh...@gmail.com writes:
   On Tue, Feb 15, 2011 at 11:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
   Robert Haas robertmh...@gmail.com writes:
   Those are good points.  My point was just that you can't actually
   build that file at the time you RUN the regression tests, because
 you
   have to build it first, then install it, then run the regression
   tests.  It could be a separate target, like 'make policy', but I
 don't
   think it works to make it part of 'make installcheck'.
  
   So?  Once you admit that you can do that, it's a matter of a couple
  more
   lines to make the installcheck target depend on the policy target
 iff
   selinux was enabled.
  
   Sure, you could do that, but I don't see what problem it would fix.
   You'd still have to build and manually install the policy before you
   could run make installcheck.  And once you've done that, you don't
   need to rebuild it every future time you run make installcheck.
  
   Oh, I see: you're pointing out the root-only semodule step that has
  to
   be done in between there.  Good point.  But the current arrangement
 is
   still a mistake: the required contents of sepgsql-regtest.pp depend
 on
   the configuration of the test system, which can't be known at build
   time.
  
   So what we should do is offer a make policy target and alter the test
   instructions to say you should do that and then run semodule.  Or maybe
   just put the whole make -f /usr/share/selinux/devel/Makefile dance
   into the instructions --- it doesn't look to me like our makefile
   infrastructure really has anything useful to add to that.
 
  Yeah, agreed.
 
 I also agree with this direction. The policy type depends on individual
 installations,
 it is not easy to assume on build time.
 Please wait for a small patch to remove this rule from Makefile and update
 documentation.
 
 As a side note, we can have a build option that does not require selinux
 enabled.
 The reason why Makefile of selinux tries to /selinux/mls is that we don't
 specify
 MLS=1 or MLS=0 explicitly.
 IIRC, the specfile of RHEL/Fedora gives all the Makefile parameters
 explicitly, thus,
 selinux does not need to be enabled on the build server.
 However, it is not a solution in this case. It is not easy to estimate the
 required
 policy type and existence of MLS support on build time.
 
 Thanks,
 --
 NEC Europe Ltd, Global Competence Center
 KaiGai Kohei kohei.kai...@eu.nec.com


sepgsql-policy.1.patch
Description: sepgsql-policy.1.patch

-- 
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] Fwd: [JDBC] Weird issues when reading UDT from stored function

2011-02-17 Thread Lukas Eder
2011/2/17 Florian Pflug f...@phlo.org

 On Feb17, 2011, at 01:14 , Oliver Jowett wrote:
  Any suggestions about how the JDBC driver can express the query to get
  the behavior that it wants? Specifically, the driver wants to call a
  particular function with N OUT or INOUT parameters (and maybe some other
  IN parameters too) and get a resultset with N columns back.

 There's no sane way to do that, I fear. You could of course look up the
 function definition in the catalog before actually calling it, but with
 overloading and polymorphic types finding the right pg_proc entry seems
 awfully complex.

 Your best option is probably to just document this caveat...


But there still is a bug in the JDBC driver as I originally documented it.
Even if you say it's not simple to know whether the signature is actually a
single UDT with 6 attributes or just 6 OUT parameters, the result is wrong
(as stated in my original mail):

The nested UDT structure completely screws up fetching results. This
 is what I get with JDBC:
 

PreparedStatement stmt = connection.prepareStatement(select *
 from p_enhance_address2());
ResultSet rs = stmt.executeQuery();

while (rs.next()) {
System.out.println(# of columns:  +
 rs.getMetaData().getColumnCount());
System.out.println(rs.getObject(1));
}
 
 Output:
 # of columns: 6
 ((Parliament Hill,77),NW31A9)


The result set meta data correctly state that there are 6 OUT columns. But
only the first 2 are actually fetched (because of a nested UDT)...


[HACKERS] rewrite of RECENTLY DEAD tuples

2011-02-17 Thread Benjamin S.

Hello list,

ATRewriteTable in tablecmds.c uses SnapshotNow to rewrite and thus
does not copy RECENTLY DEAD tuples. But copy_heap_data in cluster.c
uses SnapshotAny and copys RECENTLY DEAD tuples to the new heap
file.

I don't understand why it is not needed in the first case. In the
second case I guess that there may be still a transaction with an
older snapshot running which should be able to open the rewrited
table and see the older (RECENTLY DEAD) tuple. Why must a
transaction in the first case not be able to do so also?

Regards
Benjamin

-- 
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] SSI bug?

2011-02-17 Thread YAMAMOTO Takashi
hi,

 YAMAMOTO Takashi  wrote:
  
 with your previous patch or not?
  
 With, thanks.

i tried.  unfortunately i can still reproduce the original loop problem.

WARNING:  [0] target 0xbb51ef18 tag 4000:4017:7e3:78:0 prior 0xbb51f148 next 0xb
b51edb0
WARNING:  [1] target 0xbb51f148 tag 4000:4017:7e3:77:0 prior 0xbb51ef90 next 0xb
b51ef18
WARNING:  [2] target 0xbb51ef90 tag 4000:4017:7e3:74:0 prior 0xbb51edb0 next 0xb
b51f148
WARNING:  [3] target 0xbb51edb0 tag 4000:4017:7e3:71:0 prior 0xbb51ef18 next 0xb
b51ef90
WARNING:  found a loop

YAMAMOTO Takashi

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

-- 
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] SSI bug?

2011-02-17 Thread YAMAMOTO Takashi
hi,

 YAMAMOTO Takashi  wrote:
  
 might be unrelated to the loop problem, but...
  
 Aha!  I think it *is* related.  There were several places where data
 was uninitialized here; mostly because Dan was working on this piece
 while I was working on separate issues which added the new fields.
 I missed the interaction on integrating the two efforts.  :-(
 The uninitialized fields could lead to all the symptoms you saw.
 I've reviewed, looking for other similar issues and didn't find any.
  
 Could you try the attached patch and see if this fixes the issues
 you've seen?

with your previous patch or not?

YAMAMOTO Takashi

  
 -Kevin

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


Re: [HACKERS] SSI bug?

2011-02-17 Thread YAMAMOTO Takashi
hi,

might be unrelated to the loop problem, but...

i got the following SEGV when runnning vacuum on a table.
(the line numbers in predicate.c is different as i have local modifications.)
oldlocktag.myTarget was NULL.
it seems that TransferPredicateLocksToNewTarget sometimes use stack garbage
for newpredlocktag.myTarget.  vacuum on the table succeeded with the attached
patch.  the latter part of the patch was necessary to avoid targetList
corruption, which later seems to make DeleteChildTargetLocks loop inifinitely.

YAMAMOTO Takashi

#0  0x0823cf6c in PredicateLockAcquire (targettag=0xbfbfa734)
at predicate.c:1835
#1  0x0823f18a in PredicateLockPage (relation=0x99b4dcf0, blkno=1259)
at predicate.c:2206
#2  0x080ac978 in _bt_search (rel=0x99b4dcf0, keysz=2, scankey=0x99a05040, 
nextkey=0 '\0', bufP=0xbfbfa894, access=1) at nbtsearch.c:97
#3  0x080a996d in _bt_pagedel (rel=0x99b4dcf0, buf=value optimized out, 
stack=0x0) at nbtpage.c:1059
#4  0x080aacc2 in btvacuumscan (info=0xbfbfbcc4, stats=0x99a01328, 
callback=0x8184d50 lazy_tid_reaped, callback_state=0x99a012e0, 
cycleid=13675) at nbtree.c:981
#5  0x080ab15c in btbulkdelete (fcinfo=0xbfbfb9e0) at nbtree.c:573
#6  0x082fde74 in FunctionCall4 (flinfo=0x99b86958, arg1=3217013956, arg2=0, 
arg3=135810384, arg4=2577404640) at fmgr.c:1437
#7  0x080a4fd0 in index_bulk_delete (info=0xbfbfbcc4, stats=0x0, 
callback=0x8184d50 lazy_tid_reaped, callback_state=0x99a012e0)
at indexam.c:738
#8  0x08184cd4 in lazy_vacuum_index (indrel=0x99b4dcf0, stats=0x99a023e0, 
vacrelstats=0x99a012e0) at vacuumlazy.c:938
#9  0x081854b6 in lazy_vacuum_rel (onerel=0x99b47650, vacstmt=0x99b059d0, 
bstrategy=0x99a07018, scanned_all=0xbfbfcfd8 ) at vacuumlazy.c:762
#10 0x08184265 in vacuum_rel (relid=16424, vacstmt=0x99b059d0, 
do_toast=1 '\001', for_wraparound=0 '\0', scanned_all=0xbfbfcfd8 )
at vacuum.c:978
#11 0x081845ea in vacuum (vacstmt=0x99b059d0, relid=0, do_toast=1 '\001', 
bstrategy=0x0, for_wraparound=0 '\0', isTopLevel=1 '\001') at vacuum.c:230
#12 0xbbab50c3 in pgss_ProcessUtility (parsetree=0x99b059d0, 
queryString=0x99b05018 vacuum (verbose,analyze) pgfs.dirent;, 
params=0x0, isTopLevel=1 '\001', dest=0x99b05b80, 
completionTag=0xbfbfd21a ) at pg_stat_statements.c:603
#13 0x082499ea in PortalRunUtility (portal=0x99b33018, utilityStmt=0x99b059d0, 
isTopLevel=1 '\001', dest=0x99b05b80, completionTag=0xbfbfd21a )
at pquery.c:1191
#14 0x0824a79e in PortalRunMulti (portal=0x99b33018, isTopLevel=4 '\004', 
dest=0x99b05b80, altdest=0x99b05b80, completionTag=0xbfbfd21a )
at pquery.c:1298
#15 0x0824b21a in PortalRun (portal=0x99b33018, count=2147483647, 
isTopLevel=1 '\001', dest=0x99b05b80, altdest=0x99b05b80, 
completionTag=0xbfbfd21a ) at pquery.c:822
#16 0x08247dc7 in exec_simple_query (
query_string=0x99b05018 vacuum (verbose,analyze) pgfs.dirent;)
at postgres.c:1059
#17 0x08248a79 in PostgresMain (argc=2, argv=0xbb912650, 
username=0xbb9125c0 takashi) at postgres.c:3943
#18 0x0820e231 in ServerLoop () at postmaster.c:3590
#19 0x0820ef88 in PostmasterMain (argc=3, argv=0xbfbfe59c) at postmaster.c:1110
#20 0x081b6439 in main (argc=3, argv=0xbfbfe59c) at main.c:199
(gdb) list
1830 
offsetof(PREDICATELOCK, xactLink));
1831
1832oldlocktag = predlock-tag;
1833Assert(oldlocktag.myXact == sxact);
1834oldtarget = oldlocktag.myTarget;
1835oldtargettag = oldtarget-tag;
1836
1837if (TargetTagIsCoveredBy(oldtargettag, *newtargettag))
1838{
1839uint32  oldtargettaghash;
(gdb) 
diff --git a/src/backend/storage/lmgr/predicate.c 
b/src/backend/storage/lmgr/predicate.c
index 722d0f8..4dde6ae 100644
--- a/src/backend/storage/lmgr/predicate.c
+++ b/src/backend/storage/lmgr/predicate.c
@@ -2537,8 +2558,8 @@ TransferPredicateLocksToNewTarget(const 
PREDICATELOCKTARGETTAG oldtargettag,
if (!found)
{
SHMQueueInit((newtarget-predicateLocks));
-   newpredlocktag.myTarget = newtarget;
}
+   newpredlocktag.myTarget = newtarget;
 
oldpredlock = (PREDICATELOCK *)
SHMQueueNext((oldtarget-predicateLocks),
@@ -2588,10 +2609,12 @@ TransferPredicateLocksToNewTarget(const 
PREDICATELOCKTARGETTAG oldtargettag,
outOfShmem = true;
goto exit;
}
-   SHMQueueInsertBefore((newtarget-predicateLocks),
-
(newpredlock-targetLink));
-   
SHMQueueInsertBefore((newpredlocktag.myXact-predicateLocks),
-

[HACKERS] default_tablespace

2011-02-17 Thread carl clemens
Hi Hackers,

After reviewing docs and searching web
cannot find out how to determine the default tablespace
of a user?

Like:

select spcname from blab where roloid = ;

Is this possible?

Thank you for your time.




  

-- 
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] pika failing since the per-column collation patch

2011-02-17 Thread Rémi Zara

Le 14 févr. 2011 à 19:27, Rémi Zara a écrit :

 
 Le 12 févr. 2011 à 18:51, Peter Eisentraut a écrit :
 
 
 It's only failing on this one machine, but there isn't anything
 platform-specific in this code, so I'd look for memory management faults
 on the code or a compiler problem.  Try with lower optimization for a
 start.
 
 
 
 Same failure with -O0 (and more shared memory).
 

Hi,

Without me changing anything (still at -O0), the same error occurred but at the 
installCheck step, rather than the check step (which passed)

Anything else to try ?

Regards,

Rémi Zara
-- 
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: Fix blatantly uninitialized variable in recent commit.

2011-02-17 Thread Kevin Grittner
Tom Lane t...@sss.pgh.pa.us wrote:
 
 In at least some of these cases, I think ignoring the write()
 result is intentional, because there's really nothing useful we
 can do about it if it fails (oh, you wish we'd log a failure to
 write to the log?).
 
I know that in Java you can get a positive number less than the full
size as an indication that part of the block was written, and you
must loop to write until you get all of it written (or get an error
return).  At this page, it appears that the same is true of the
write function in C:
 
http://www.gnu.org/s/libc/manual/html_node/I_002fO-Primitives.html
 
Quoting from that page:
 
| The return value is the number of bytes actually written. This may
| be size, but can always be smaller. Your program should always
| call write in a loop, iterating until all the data is written. 
 
Isn't that the write function we're calling?  If so, are you
maintaining that the gnu.org documentation of this function is
wrong?
 
-Kevin

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


Re: [HACKERS] Debian readline/libedit breakage

2011-02-17 Thread Andrew Dunstan



On 02/17/2011 11:58 AM, Bruce Momjian wrote:

Andrew Dunstan wrote:


On 02/17/2011 11:44 AM, Bruce Momjian wrote:

Andrew Dunstan wrote:

On 02/17/2011 11:22 AM, Bruce Momjian wrote:

psql used to use the native Windows line editing ability --- has that
changed?

When did it? Ad what native windows line editing ability are you
referring to?

There is native Windows editing like arrows, etc and history, though the
history is not kept between sessions.  If windows is now using readline,
then odds are we are shipping libreadline to make that happen, and we
are then linking using a supplied GPL library (and we don't have the
OS-installed exception).  I hope I am wrong.


Readline has always been disabled on Windows builds AFAIK. Just look at
the buildfarm traces. Here's an example from
http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=frogmouthdt=2011-02-17%2015%3A30%3A03stg=configure

 configure: WARNING: *** Readline does not work on MinGW --- disabling


It's not used in MSVC either, IIRC.


OK, I was only responding to Stephen Frost who said psql did not behave
like other Windows apps.


I think both of you have possibly been under a misapprehension. All this 
discussion about the Windows installers is entirely irrelevant to this 
thread, ISTM, since there is no readline use in them.


FWIW, the only interactively usable version of psql for windows I know 
of is the one that runs under Cygwin. It can be build with readline and 
works as expected.


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] Debian readline/libedit breakage

2011-02-17 Thread Bruce Momjian
Andrew Dunstan wrote:
 
 
 On 02/17/2011 11:58 AM, Bruce Momjian wrote:
  Andrew Dunstan wrote:
 
  On 02/17/2011 11:44 AM, Bruce Momjian wrote:
  Andrew Dunstan wrote:
  On 02/17/2011 11:22 AM, Bruce Momjian wrote:
  psql used to use the native Windows line editing ability --- has that
  changed?
  When did it? Ad what native windows line editing ability are you
  referring to?
  There is native Windows editing like arrows, etc and history, though the
  history is not kept between sessions.  If windows is now using readline,
  then odds are we are shipping libreadline to make that happen, and we
  are then linking using a supplied GPL library (and we don't have the
  OS-installed exception).  I hope I am wrong.
 
  Readline has always been disabled on Windows builds AFAIK. Just look at
  the buildfarm traces. Here's an example from
  http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=frogmouthdt=2011-02-17%2015%3A30%3A03stg=configure
 
   configure: WARNING: *** Readline does not work on MinGW --- disabling
 
 
  It's not used in MSVC either, IIRC.
 
  OK, I was only responding to Stephen Frost who said psql did not behave
  like other Windows apps.
 
 I think both of you have possibly been under a misapprehension. All this 
 discussion about the Windows installers is entirely irrelevant to this 
 thread, ISTM, since there is no readline use in them.

OK, that's what I thought.

 FWIW, the only interactively usable version of psql for windows I know 
 of is the one that runs under Cygwin. It can be build with readline and 
 works as expected.

Uh, don't we have a psql built via MSVC?  Doesn't it work interactively?

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
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] contrib loose ends: 9.0 to 9.1 incompatibilities

2011-02-17 Thread Tom Lane
So, after some testing, attached are two different fixed-up versions of
pg_tgrm's update-from-unpackaged script.  The first one leaves the
parameter lists of some GIN support functions different from what they
would be if you installed pg_trgrm fresh in 9.1.  The second one fixes
the parameter lists too, by means of really ugly direct UPDATEs on
pg_proc.  I'm unsure which one to apply --- any opinions?

It's worth noting that both versions still leave the pg_trgm opclasses a
bit different from a fresh install, because the added operators are
loose in the opfamily rather than being bound into the opclass.  This
hasn't got any real functional effect, but if you were feeling paranoid
you could worry about whether the two different states could cause
problems for future versions of the update script.  As far as I can see,
the only thing we could realistically do about this with the tools at
hand is to change pg_trgm's install script so that it also creates the
new-in-9.1 entries loose.  That seems a tad ugly, but depending on
where you stand on the paranoia scale you might think it's a good idea.
There is definitely no point in that refinement unless we update the
function parameter lists, though.

Comments?

regards, tom lane

/* contrib/pg_trgm/pg_trgm--unpackaged--1.0.sql */

ALTER EXTENSION pg_trgm ADD function set_limit(real);
ALTER EXTENSION pg_trgm ADD function show_limit();
ALTER EXTENSION pg_trgm ADD function show_trgm(text);
ALTER EXTENSION pg_trgm ADD function similarity(text,text);
ALTER EXTENSION pg_trgm ADD function similarity_op(text,text);
ALTER EXTENSION pg_trgm ADD operator %(text,text);
ALTER EXTENSION pg_trgm ADD type gtrgm;
ALTER EXTENSION pg_trgm ADD function gtrgm_in(cstring);
ALTER EXTENSION pg_trgm ADD function gtrgm_out(gtrgm);
ALTER EXTENSION pg_trgm ADD function gtrgm_consistent(internal,text,integer,oid,internal);
ALTER EXTENSION pg_trgm ADD function gtrgm_compress(internal);
ALTER EXTENSION pg_trgm ADD function gtrgm_decompress(internal);
ALTER EXTENSION pg_trgm ADD function gtrgm_penalty(internal,internal,internal);
ALTER EXTENSION pg_trgm ADD function gtrgm_picksplit(internal,internal);
ALTER EXTENSION pg_trgm ADD function gtrgm_union(bytea,internal);
ALTER EXTENSION pg_trgm ADD function gtrgm_same(gtrgm,gtrgm,internal);
ALTER EXTENSION pg_trgm ADD operator family gist_trgm_ops using gist;
ALTER EXTENSION pg_trgm ADD operator class gist_trgm_ops using gist;
ALTER EXTENSION pg_trgm ADD operator family gin_trgm_ops using gin;
ALTER EXTENSION pg_trgm ADD operator class gin_trgm_ops using gin;

-- These functions had different names/signatures in 9.0.  We can't just
-- drop and recreate them because they are linked into the GIN opclass,
-- so we need some hacks.

-- First, absorb them into the extension under their old names.

ALTER EXTENSION pg_trgm ADD function gin_extract_trgm(text, internal);
ALTER EXTENSION pg_trgm ADD function gin_extract_trgm(text, internal, int2, internal, internal);
ALTER EXTENSION pg_trgm ADD function gin_trgm_consistent(internal,smallint,text,integer,internal,internal);

-- Fix the names, and then do CREATE OR REPLACE to adjust the function
-- bodies to be correct (ie, reference the correct C symbol).  We do not
-- attempt to change the parameter lists, however.  It's not necessary
-- since GIN doesn't care, and there's no clean way to do it.

ALTER FUNCTION gin_extract_trgm(text, internal)
  RENAME TO gin_extract_value_trgm;
CREATE OR REPLACE FUNCTION gin_extract_value_trgm(text, internal)
RETURNS internal
AS 'MODULE_PATHNAME'
LANGUAGE C IMMUTABLE STRICT;

ALTER FUNCTION gin_extract_trgm(text, internal, int2, internal, internal)
  RENAME TO gin_extract_query_trgm;
CREATE OR REPLACE FUNCTION gin_extract_query_trgm(text, internal, int2, internal, internal)
RETURNS internal
AS 'MODULE_PATHNAME'
LANGUAGE C IMMUTABLE STRICT;

-- gin_trgm_consistent didn't change name, so nothing more to do for it.

-- These were not in 9.0:

CREATE FUNCTION similarity_dist(text,text)
RETURNS float4
AS 'MODULE_PATHNAME'
LANGUAGE C STRICT IMMUTABLE;

CREATE OPERATOR - (
LEFTARG = text,
RIGHTARG = text,
PROCEDURE = similarity_dist,
COMMUTATOR = '-'
);

CREATE FUNCTION gtrgm_distance(internal,text,int,oid)
RETURNS float8
AS 'MODULE_PATHNAME'
LANGUAGE C IMMUTABLE STRICT;

-- Add new stuff to the operator classes.  Note this will result in the
-- added stuff being loose in the operator family, rather than bound
-- into the operator class as it would be when creating the extension
-- from scratch.  That shouldn't be problematic.

ALTER OPERATOR FAMILY gist_trgm_ops USING gist ADD
OPERATOR2   - (text, text) FOR ORDER BY pg_catalog.float_ops,
OPERATOR3   pg_catalog.~~ (text, text),
OPERATOR4   pg_catalog.~~* (text, text),
FUNCTION8 (text, text)   gtrgm_distance (internal, text, int, oid);

ALTER OPERATOR FAMILY gin_trgm_ops USING gin ADD
OPERATOR3   

Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.

2011-02-17 Thread Tom Lane
Kevin Grittner kevin.gritt...@wicourts.gov writes:
 Tom Lane t...@sss.pgh.pa.us wrote:
 Would you check whether just casting the function result to (void)
 shuts it up?
 
 Casting the result to (void) didn't change the warning.  It shut up
 when I declared a local variable and assigned the value to it (which
 was then never used).

Too bad.  I believe gcc 4.6 will warn about *that*, so it's not going to
be much of an improvement for long.

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] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.

2011-02-17 Thread Tom Lane
Kevin Grittner kevin.gritt...@wicourts.gov writes:
 I know that in Java you can get a positive number less than the full
 size as an indication that part of the block was written, and you
 must loop to write until you get all of it written (or get an error
 return).  At this page, it appears that the same is true of the
 write function in C:

This is appropriate when writing to sockets etc, where the kernel is
willing to reflect details like packet boundaries back to userspace.
I have never seen nor heard of it being true for writes to disk files,
except for the case of out-of-disk-space, in which it is quite unlikely
that looping is a good thing to do.

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] Debian readline/libedit breakage

2011-02-17 Thread Stephen Frost
* Bruce Momjian (br...@momjian.us) wrote:
 OK, I was only responding to Stephen Frost who said psql did not behave
 like other Windows apps.

I don't actually run psql or PG on Windows at all, I just presumed it
did since you were bringing up concerns about it in the Windows
installers.  Ah well, sorry for the confusion. :)

Thanks,

Stephen


signature.asc
Description: Digital signature


Re: [HACKERS] Debian readline/libedit breakage

2011-02-17 Thread Andrew Dunstan



On 02/17/2011 12:13 PM, Bruce Momjian wrote:



FWIW, the only interactively usable version of psql for windows I know
of is the one that runs under Cygwin. It can be build with readline and
works as expected.

Uh, don't we have a psql built via MSVC?  Doesn't it work interactively?



Not if you want readline. And in my book that's a requirement of a psql 
that's usable interactively. It's pretty horrible to use without it.


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] Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.

2011-02-17 Thread Andrew Dunstan



On 02/17/2011 12:19 PM, Tom Lane wrote:

Kevin Grittnerkevin.gritt...@wicourts.gov  writes:

Tom Lanet...@sss.pgh.pa.us  wrote:

Would you check whether just casting the function result to (void)
shuts it up?



Casting the result to (void) didn't change the warning.  It shut up
when I declared a local variable and assigned the value to it (which
was then never used).

Too bad.  I believe gcc 4.6 will warn about *that*, so it's not going to
be much of an improvement for long.




Ugh. Isn't there some sort of pragma or similar we can use to shut it up?

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

2011-02-17 Thread David Kerr
On Wed, Feb 16, 2011 at 03:59:13PM -0800, carl clemens wrote:
- Hi Hackers,
- 
- After reviewing docs and searching web
- cannot find out how to determine the default tablespace
- of a user?
- 
- Like:
- 
- select spcname from blab where roloid = ;
- 
- Is this possible?
- 
- Thank you for your time.
- 

It doesn't appear to me that default tablespaces are assigned to a user, 
they're 
assigned to a database.

A user can set the variable default_tablespace in their session to over-ride 
the 
database default, but that wouldn't be stored anywhere in the database (it's a 
client
variable). 

you can find the OID for the default tablespace for a specific database in 
pg_database.

more info:
http://www.postgresql.org/docs/9.0/static/runtime-config-client.html#GUC-DEFAULT-TABLESPACE

Dave

-- 
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] Debian readline/libedit breakage

2011-02-17 Thread Bruce Momjian
Stephen Frost wrote:
-- Start of PGP signed section.
 * Bruce Momjian (br...@momjian.us) wrote:
  I just posted on this.  The risk is to people using the packages --- the
  packages themselves include the source as an option, so they are fine,
  but everyone using those packages would also be required to distribute
  source, which is a restriction we have avoided in the past.
 
 I think you may want to reread the GPL on this.  They're not actually
 required to distribute source *with* the binaries (hell, Debian
 doesn't..) as long as they are willing to produce it if asked.  And
 that's the source for the binaries which actually depend on the GPL'd
 code, eg, the community-built psql binary that you're talking about
 here..  They don't have to provide source for everything on the CD or
 something (again, Debian has a non-free section also..).

In summary, our click-through installers and hopefully other packaged
versions of Postgres don't distribute libreadline and rely on the
OS-supplied version, which is a FSF exception.  As I mentioned,
distributing the installer source doesn't exempt others from having to
GPL when they add to it (again, kind of rare because you can't link
something to psql, but anyway, it is mostly perception).

Debian distributes both Postgres and libreadline, so my guess is they
don't think they can use that exception and therefore have a problem.

And, again, libedit is not as hard as many of the problems we have
solved.  Since we have grown strong, I would love to see us reaching out
to those satellite communities and helping them solve some of their
problems, though, as people pointed out, in a way that does not take
energy away from Postgres development.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
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] Debian readline/libedit breakage

2011-02-17 Thread Bruce Momjian
Andrew Dunstan wrote:
 
 
 On 02/17/2011 12:13 PM, Bruce Momjian wrote:
 
  FWIW, the only interactively usable version of psql for windows I know
  of is the one that runs under Cygwin. It can be build with readline and
  works as expected.
  Uh, don't we have a psql built via MSVC?  Doesn't it work interactively?
 
 
 Not if you want readline. And in my book that's a requirement of a psql 
 that's usable interactively. It's pretty horrible to use without it.

Well, as horrible as other Windows apps.  I will leave others to decide
if that is usable.  ;-)  I am unclear if we would ship readline support
on Windows even if we didn't have a license issue (no OS readline
version on Windows).

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
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] rewrite of RECENTLY DEAD tuples

2011-02-17 Thread Noah Misch
On Thu, Feb 17, 2011 at 09:38:51AM +0100, Benjamin S. wrote:
 ATRewriteTable in tablecmds.c uses SnapshotNow to rewrite and thus
 does not copy RECENTLY DEAD tuples. But copy_heap_data in cluster.c
 uses SnapshotAny and copys RECENTLY DEAD tuples to the new heap
 file.
 
 I don't understand why it is not needed in the first case. In the
 second case I guess that there may be still a transaction with an
 older snapshot running which should be able to open the rewrited
 table and see the older (RECENTLY DEAD) tuple. Why must a
 transaction in the first case not be able to do so also?

Unlike VACUUM FULL and CLUSTER, ALTER TABLE rewrites are not MVCC-safe.  No
visibility-relevant information is preserved; all tuples get the xmin of the
ALTER TABLE transaction.  The table will look empty to snapshots predating the
commit of the ALTER TABLE transaction.  Compare TRUNCATE.

All other things being equal, it would be nice for ALTER TABLE rewrites to
become MVCC-safe.  The main implication is that tuples not visible to us can
cause the operation to fail.  Example:

CREATE TABLE t (x int);
CREATE DOMAIN int_notnull AS int NOT NULL;
INSERT INTO t VALUES (NULL);
-- acquire a snapshot in some other session here
DELETE FROM t;
ALTER TABLE t ALTER x TYPE int_notnull; -- error converting deleted tuple

If we also made the error message sufficiently informative, I'd wager this would
be a net improvement for the average user.

Thanks,
nm

-- 
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] patch (for 9.1) string functions ( correct patch attached )

2011-02-17 Thread Bruce Momjian
Erik Rijkers wrote:
 On Thu, July 29, 2010 22:43, Erik Rijkers wrote:
  Hi Pavel,
 
  In xfunc.sgml, I came across a function example (for use of VARIADIC in 
  polymorphic functions),
  where the function name is concat():  (in the manual: 35.4.10. Polymorphic 
  SQL Functions).
  Although that is not strictly wrong, it seems better to change that name 
  when concat goes into
  core, as seems to be the plan.
 
  If you agree, it seems best to include this change in your patch and change 
  that example
  function's name when the stringfunc patch gets applied.
 
 
 My apologies, the previous email had the wrong doc-patch attached.
 
 Here is the correct one.

Applied for 9.1.  Thanks.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
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] ECPG dynamic cursor fix for UPDATE/DELETE ... WHERE CURRENT OF :curname

2011-02-17 Thread Bruce Momjian
Boszormenyi Zoltan wrote:
 Kevin Grittner ?rta:
  Michael Meskes mich...@fam-meskes.de wrote:

  All prior ECPG versions were fine because dynamic cursor names
  were only added in 9.0.  Apparently only this one place was
  missed. So this is a bug in the new feature, however not such a
  major one that it warrants the complete removal IMO. I'd prefer to
  fix this in 9.0.1.
  
 
 As we are so late in the beta phase, we can live with that, hopefully
 you will find time by then to review the patch which is actually not
 that complex, only a bit large. The part of ECPGdo() that deals with
 auto-preparing statements is moved closer to calling ecpg_execute(),
 after the varargs are converted to stmt-inlist and -outlist.
 
  Hope this cleans it up a bit.
  
   
  Thanks.  I think I get it now.
   
  To restate from another angle, to confirm my understanding: UPDATE
  WHERE CURRENT OF is working for cursors with the name hard-coded in
  the embedded statement, which is the only way cursor names were
  allowed to be specified prior to 9.0; 9.0 implements dynamic cursor
  names, allowing you to use a variable for the cursor name; but this
  one use of a cursor name isn't allowing a variable yet.  Do I have
  it right?  (If so, I now see why it would be considered a bug.)

 
 Yes, you understand it correctly.

Did this ever get applied?  If so, I can't find it.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
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: Fix blatantly uninitialized variable in recent commit.

2011-02-17 Thread Kevin Grittner
Andrew Dunstan and...@dunslane.net wrote:
 
 Ugh. Isn't there some sort of pragma or similar we can use to shut
 it up?
 
If that fails, maybe use some function like the below?  That would
also have the advantage of not relying on assumptions beyond the
documented API, which I tend to feel good about no matter how sure I
am that the implementation details upon which I'm relying won't
change.
 
No claims that this is good final form, especially when it comes to
using ssize_t, but just trying to get across the general idea:
 
void
write_completely_ignore_errors(int filedes, const void *buffer,
   size_t size)
{
size_t t = 0;
while (t  size)
{
ssize_t n = write(filedes, buffer, size - t);
if (n = 0)
break;
t += n;
}
}
 
-Kevin

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


Re: [HACKERS] Rewrite, normal execution vs. EXPLAIN ANALYZE

2011-02-17 Thread Bruce Momjian
Tom Lane wrote:
 Robert Haas robertmh...@gmail.com writes:
  On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
  I seriously doubt that there are many applications out there that are
  actually depending on this aspect of rule execution; if anything, there
  are probably more that will see it as a bug.
 
  Changing EXPLAIN ANALYZE seems a bit less likely to break things for
  anyone depending on current behavior;
 
 Well, the point I was trying to make is that there may well be fewer
 people depending on the current behavior than there are people for whom
 the current behavior is wrong, only they don't know it because they've
 not seen a failure (or not seen one often enough to diagnose what's
 happening).
 
 This is of course merest speculation either way.  But I don't feel that
 we need to necessarily treat rule behavior as graven in stone.

Where are we on this?  It seems it is an issue independent of writable
common table expressions (wCTEs).

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
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] Rewrite, normal execution vs. EXPLAIN ANALYZE

2011-02-17 Thread Robert Haas
On Thu, Feb 17, 2011 at 1:04 PM, Bruce Momjian br...@momjian.us wrote:
 Tom Lane wrote:
 Robert Haas robertmh...@gmail.com writes:
  On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
  I seriously doubt that there are many applications out there that are
  actually depending on this aspect of rule execution; if anything, there
  are probably more that will see it as a bug.

  Changing EXPLAIN ANALYZE seems a bit less likely to break things for
  anyone depending on current behavior;

 Well, the point I was trying to make is that there may well be fewer
 people depending on the current behavior than there are people for whom
 the current behavior is wrong, only they don't know it because they've
 not seen a failure (or not seen one often enough to diagnose what's
 happening).

 This is of course merest speculation either way.  But I don't feel that
 we need to necessarily treat rule behavior as graven in stone.

 Where are we on this?  It seems it is an issue independent of writable
 common table expressions (wCTEs).

I believe that it's the same issue as this patch:

https://commitfest.postgresql.org/action/patch_view?id=377

The status of that patch is that Tom promised to look at it two months
ago and hasn't.  It would be nice if someone else could pick it up.
It's not good for our community to ignore patches that people have
taken the trouble to write and submit.

-- 
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] Debian readline/libedit breakage

2011-02-17 Thread Joshua D. Drake
On Thu, 2011-02-17 at 10:49 +, Dave Page wrote:
 On Thu, Feb 17, 2011 at 10:36 AM, Magnus Hagander mag...@hagander.net wrote:

  Probably readline but does it matter? We distribute the source to the
  click installers.
 
  Actually, we don't. We used to, but we don't at this point.
 
 Depends on your definition of distribute (and what part you are
 specifically referring to). There's no tarball, but the installer
 sources are on git.postgresql.org.

Right, and that qualifies.

JD

-- 
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering
http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt


-- 
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] Debian readline/libedit breakage

2011-02-17 Thread Andrew Dunstan



On 02/17/2011 12:34 PM, Bruce Momjian wrote:

Andrew Dunstan wrote:


On 02/17/2011 12:13 PM, Bruce Momjian wrote:

FWIW, the only interactively usable version of psql for windows I know
of is the one that runs under Cygwin. It can be build with readline and
works as expected.

Uh, don't we have a psql built via MSVC?  Doesn't it work interactively?


Not if you want readline. And in my book that's a requirement of a psql
that's usable interactively. It's pretty horrible to use without it.

Well, as horrible as other Windows apps.  I will leave others to decide
if that is usable.  ;-)  I am unclear if we would ship readline support
on Windows even if we didn't have a license issue (no OS readline
version on Windows).



Windows developers almost universally work from GUIs and not using 
console apps (and that's true of many Unix developers also, particularly 
those who can't recall a time when X-Windows wasn't almost universally 
available). Microsoft has de-emphasized console apps for 15 years. So 
the only people who are likely to be interested in using an enhanced 
psql on Windows are old Unix-heads like you and me. It's not worth a lot 
of effort, IMNSHO.


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] Rewrite, normal execution vs. EXPLAIN ANALYZE

2011-02-17 Thread Bruce Momjian
Robert Haas wrote:
 On Thu, Feb 17, 2011 at 1:04 PM, Bruce Momjian br...@momjian.us wrote:
  Tom Lane wrote:
  Robert Haas robertmh...@gmail.com writes:
   On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
   I seriously doubt that there are many applications out there that are
   actually depending on this aspect of rule execution; if anything, there
   are probably more that will see it as a bug.
 
   Changing EXPLAIN ANALYZE seems a bit less likely to break things for
   anyone depending on current behavior;
 
  Well, the point I was trying to make is that there may well be fewer
  people depending on the current behavior than there are people for whom
  the current behavior is wrong, only they don't know it because they've
  not seen a failure (or not seen one often enough to diagnose what's
  happening).
 
  This is of course merest speculation either way. ?But I don't feel that
  we need to necessarily treat rule behavior as graven in stone.
 
  Where are we on this? ?It seems it is an issue independent of writable
  common table expressions (wCTEs).
 
 I believe that it's the same issue as this patch:
 
 https://commitfest.postgresql.org/action/patch_view?id=377
 
 The status of that patch is that Tom promised to look at it two months
 ago and hasn't.  It would be nice if someone else could pick it up.
 It's not good for our community to ignore patches that people have
 taken the trouble to write and submit.

Oh, at least it is in the current commit-fest and was not lost.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
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] remove upsert example from docs

2011-02-17 Thread Bruce Momjian
Marko Tiikkaja wrote:
 On 8/5/2010 9:44 PM, Merlin Moncure wrote:
  On Thu, Aug 5, 2010 at 2:09 PM, Tom Lanet...@sss.pgh.pa.us  wrote:
  I was not persuaded that there's a real bug in practice.  IMO, his
  problem was a broken trigger not broken upsert logic.  Even if we
  conclude this is unsafe, simply removing the example is of no help to
  anyone.
 
  Well, the error handler is assuming that the unique_volation is coming
  from the insert made within the loop.  This is obviously not a safe
  assumption in an infinite loop context.  It should be double checking
  where the error was being thrown from -- but the only way I can think
  of to do that is to check sqlerrm.
 
 Yeah, this is a known problem with our exception system.  If there was 
 an easy and reliable way of knowing where the exception came from, I'm 
 sure the example would include that.
 
  Or you arguing that if you're
  doing this, all dependent triggers must not throw unique violations up
  the exception chain?
 
 If he isn't, I am.  I'm pretty sure you can break every example in the 
 docs with a trigger (or a rule) you haven't thought through.
 
  A more useful response would be to supply a correct example.
  Agree: I'd go further I would argue to supply both the 'safe' and
  'high concurrency (with caveat)' way.  I'm not saying the example is
  necessarily bad, just that it's maybe not a good thing to be pointing
  as a learning example without qualifications.  Then you get a lesson
  both on upsert methods and defensive error handling (barring
  objection, I'll provide that).
 
 The problem with the safe way is that it's not safe if called in a 
 transaction with isolation level set to SERIALIZABLE.

Good analysis.  Documentation patch attached and applied.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index c342916..d2e74dc 100644
*** a/doc/src/sgml/plpgsql.sgml
--- b/doc/src/sgml/plpgsql.sgml
*** BEGIN
*** 2464,2470 
  INSERT INTO db(a,b) VALUES (key, data);
  RETURN;
  EXCEPTION WHEN unique_violation THEN
! -- do nothing, and loop to try the UPDATE again
  END;
  END LOOP;
  END;
--- 2464,2470 
  INSERT INTO db(a,b) VALUES (key, data);
  RETURN;
  EXCEPTION WHEN unique_violation THEN
! -- Do nothing, and loop to try the UPDATE again.
  END;
  END LOOP;
  END;
*** LANGUAGE plpgsql;
*** 2474,2480 
  SELECT merge_db(1, 'david');
  SELECT merge_db(1, 'dennis');
  /programlisting
! 
  /para
  /example
/sect2
--- 2474,2483 
  SELECT merge_db(1, 'david');
  SELECT merge_db(1, 'dennis');
  /programlisting
!  This example assumes the literalunique_violation/ error is caused by
!  the commandINSERT/, and not by an commandINSERT/ trigger function
!  on the table.  Also, this example only works in the default Read
!  Committed transaction mode.
  /para
  /example
/sect2

-- 
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] contrib loose ends: 9.0 to 9.1 incompatibilities

2011-02-17 Thread Robert Haas
On Thu, Feb 17, 2011 at 12:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 So, after some testing, attached are two different fixed-up versions of
 pg_tgrm's update-from-unpackaged script.  The first one leaves the
 parameter lists of some GIN support functions different from what they
 would be if you installed pg_trgrm fresh in 9.1.  The second one fixes
 the parameter lists too, by means of really ugly direct UPDATEs on
 pg_proc.  I'm unsure which one to apply --- any opinions?

 It's worth noting that both versions still leave the pg_trgm opclasses a
 bit different from a fresh install, because the added operators are
 loose in the opfamily rather than being bound into the opclass.  This
 hasn't got any real functional effect, but if you were feeling paranoid
 you could worry about whether the two different states could cause
 problems for future versions of the update script.  As far as I can see,
 the only thing we could realistically do about this with the tools at
 hand is to change pg_trgm's install script so that it also creates the
 new-in-9.1 entries loose.  That seems a tad ugly, but depending on
 where you stand on the paranoia scale you might think it's a good idea.
 There is definitely no point in that refinement unless we update the
 function parameter lists, though.

 Comments?

I think we should try to make the state match as closely as possible,
no matter how you got there.  Otherwise, I think we're storing up a
host of future pain for ourselves.

-- 
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] remove upsert example from docs

2011-02-17 Thread Marko Tiikkaja

On 2011-02-17 8:37 PM +0200, Bruce Momjian wrote:

Marko Tiikkaja wrote:

The problem with the safe way is that it's not safe if called in a
transaction with isolation level set to SERIALIZABLE.


Good analysis.  Documentation patch attached and applied.


The safe way I was referring to above was the LOCK TABLE method, not 
the one described in the documentation, so the remark about READ 
COMMITTED in the patch should be removed.  The first part looks fine though.



Regards,
Marko Tiikkaja

--
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] contrib loose ends: 9.0 to 9.1 incompatibilities

2011-02-17 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes:
 On Thu, Feb 17, 2011 at 12:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 It's worth noting that both versions still leave the pg_trgm opclasses a
 bit different from a fresh install, because the added operators are
 loose in the opfamily rather than being bound into the opclass.  This
 hasn't got any real functional effect, but if you were feeling paranoid
 you could worry about whether the two different states could cause
 problems for future versions of the update script.  As far as I can see,
 the only thing we could realistically do about this with the tools at
 hand is to change pg_trgm's install script so that it also creates the
 new-in-9.1 entries loose.  That seems a tad ugly, but depending on
 where you stand on the paranoia scale you might think it's a good idea.
 There is definitely no point in that refinement unless we update the
 function parameter lists, though.
 
 Comments?

 I think we should try to make the state match as closely as possible,
 no matter how you got there.  Otherwise, I think we're storing up a
 host of future pain for ourselves.

Well, if you're willing to hold your nose for the UPDATE pg_proc hack,
we can make it so.

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] COPY ENCODING revisited

2011-02-17 Thread Robert Haas
On Wed, Feb 16, 2011 at 10:45 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
 COPY ENCODING patch was returned with feedback,
  https://commitfest.postgresql.org/action/patch_view?id=501
 but we still need it for file_fdw.  Using client_encoding at runtime
 is reasonable for one-time COPY command, but logically nonsense for
 persistent file_fdw tables.

 Base on the latest patch,
  http://archives.postgresql.org/pgsql-hackers/2011-01/msg02903.php
 I added pg_any_to_server() and pg_server_to_any() functions instead of
 exposing FmgrInfo in pg_wchar.h.  They are same as pg_client_to_server()
 and pg_server_to_client(), but accept any encoding. They use cached
 conversion procs only if the specified encoding matches the client encoding.

 According to Harada's research,
  http://archives.postgresql.org/pgsql-hackers/2011-01/msg02397.php
 non-cached conversions are slower than cached ones. This version provides
 the same performance before when file and client encoding are same,
 but would be a bit slower on other cases. We could improve the performance
 in future versions, for example, caching each used conversion proc in
 pg_do_pg_do_encoding_conversion().

 file_fdw will support ENCODING option. Also, if not specified it might
 have to store the client_encoding at CREATE FOREIGN TABLE. Even if we use
 a different client_encoding at SELECT, the encoding at definition is used.

 ENCODING 'quoted name' issue is also fixed; it always requires quoted names.
 I think we only accept non-quoted text as identifier names. Unquoted text
 should be treated as double quoted, but encoding names are not identifiers.

I am not qualified to fully review this patch because I'm not all that
familiar with the encoding stuff, but it looks reasonably sensible on
a quick read-through.  I am supportive of making a change in this area
even at this late date, because it seems to me that if we're not going
to change this then we're pretty much giving up on having a usable
file_fdw in 9.1.  And since postgresql_fdw isn't in very good shape
either, that would mean we may as well give up on SQL/MED.  We might
have to do that anyway, but I don't think we should do it just because
of this issue, if there's a reasonable fix.

I don't think the fact that the performance bites is a reason not to
do this.  As you say, that can always be improved in the future.

-- 
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] contrib loose ends: 9.0 to 9.1 incompatibilities

2011-02-17 Thread Robert Haas
On Thu, Feb 17, 2011 at 1:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 Robert Haas robertmh...@gmail.com writes:
 On Thu, Feb 17, 2011 at 12:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 It's worth noting that both versions still leave the pg_trgm opclasses a
 bit different from a fresh install, because the added operators are
 loose in the opfamily rather than being bound into the opclass.  This
 hasn't got any real functional effect, but if you were feeling paranoid
 you could worry about whether the two different states could cause
 problems for future versions of the update script.  As far as I can see,
 the only thing we could realistically do about this with the tools at
 hand is to change pg_trgm's install script so that it also creates the
 new-in-9.1 entries loose.  That seems a tad ugly, but depending on
 where you stand on the paranoia scale you might think it's a good idea.
 There is definitely no point in that refinement unless we update the
 function parameter lists, though.

 Comments?

 I think we should try to make the state match as closely as possible,
 no matter how you got there.  Otherwise, I think we're storing up a
 host of future pain for ourselves.

 Well, if you're willing to hold your nose for the UPDATE pg_proc hack,
 we can make it so.

Yes, I think that's better than leaving things in a different state.
It's not my first choice, but it's better than the alternative.

-- 
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] COPY ENCODING revisited

2011-02-17 Thread Hitoshi Harada
2011/2/17 Itagaki Takahiro itagaki.takah...@gmail.com:
 Base on the latest patch,
  http://archives.postgresql.org/pgsql-hackers/2011-01/msg02903.php
 I added pg_any_to_server() and pg_server_to_any() functions instead of
 exposing FmgrInfo in pg_wchar.h.  They are same as pg_client_to_server()
 and pg_server_to_client(), but accept any encoding. They use cached
 conversion procs only if the specified encoding matches the client encoding.

It sounds good to me since the approach doesn't make any overhead to
the current behavior, although additional ENCODING option usage gets a
bit slower. Nothing lost.

FWIW, I finally found the good example to cache miscellaneous data in
file local, namely regexp.c. It allocates compiled regular expressions
up to 32 by using malloc(). We need only 4 or so for encoding
conversion cache, in which cache search doesn't seem like overhead. I
don't have time to make it as patch, but in a few days I'll try it.

Regards,


-- 
Hitoshi Harada

-- 
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: Fix blatantly uninitialized variable in recent commit.

2011-02-17 Thread Andrew Dunstan



On 02/17/2011 12:54 PM, Kevin Grittner wrote:

Andrew Dunstanand...@dunslane.net  wrote:


Ugh. Isn't there some sort of pragma or similar we can use to shut
it up?


If that fails, maybe use some function like the below?  That would
also have the advantage of not relying on assumptions beyond the
documented API, which I tend to feel good about no matter how sure I
am that the implementation details upon which I'm relying won't
change.

No claims that this is good final form, especially when it comes to
using ssize_t, but just trying to get across the general idea:

void
write_completely_ignore_errors(int filedes, const void *buffer,
size_t size)
{
 size_t t = 0;
 while (t  size)
 {
 ssize_t n = write(filedes, buffer, size - t);
 if (n= 0)
 break;
 t += n;
 }
}



In a very modern gcc, where we seem to be getting the errors from, maybe

   |#pragma GCC diagnostic push
   |#pragma GCC diagnostic ignored -Wunused-result
   write( ...);
   #pragma GCC diagnostic pop


would work. See 
http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html#Diagnostic-Pragmas


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


  1   2   >