Re: [HACKERS] Proposal: new border setting in psql

2008-08-22 Thread Martijn van Oosterhout
On Thu, Aug 21, 2008 at 11:18:24PM -0400, D'Arcy J.M. Cain wrote:
  I think it does -- I used to use the Latex output format for easy cut'n
  pasting.  ReST sounds like it serves the same purpose.  If I had had to
  use conversion to XML, it would have been rather painful.
 
 ReST is nice because it's almost plain text.  In fact, a ReST document
 source can easily be read raw.

I presume by ReST you mean this:
http://docutils.sourceforge.net/rst.html

Just guessing though. It's not referenced in wikipedia under that
acronym.

Have a nice day,
-- 
Martijn van Oosterhout   [EMAIL PROTECTED]   http://svana.org/kleptog/
 Please line up in a tree and maintain the heap invariant while 
 boarding. Thank you for flying nlogn airlines.


signature.asc
Description: Digital signature


Re: [HACKERS] Proposal: new border setting in psql

2008-08-22 Thread D'Arcy J.M. Cain
On Fri, 22 Aug 2008 08:23:01 +0200
Martijn van Oosterhout [EMAIL PROTECTED] wrote:
 On Thu, Aug 21, 2008 at 11:18:24PM -0400, D'Arcy J.M. Cain wrote:
  ReST is nice because it's almost plain text.  In fact, a ReST document
  source can easily be read raw.
 
 I presume by ReST you mean this:
 http://docutils.sourceforge.net/rst.html

Yes.  See the original message in this thread.

-- 
D'Arcy J.M. Cain [EMAIL PROTECTED] |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.

-- 
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] [FINALLY] the TODO list has migrated to Wiki

2008-08-22 Thread Albert Cervera i Areny
A Divendres 22 Agost 2008, Alvaro Herrera va escriure:
 Alvaro Herrera escribió:
  They did not merge with the text, but they were not searchable.  May I
  suggest using the text [easy] and [done] instead?  That way, it is
  searchable, and they don't merge with the text.

 I just made this change.  What I now notice is that both markers are
 visually not very different.  I don't know if this is something worth
 fussing about.  (Maybe the addition of icons as Brendan was suggesting
 would be sufficient visual clue.)

Thanks. Maybe setting [easy] in orange and [done] in green would solve that 
too.


 --
 Alvaro Herrerahttp://www.CommandPrompt.com/
 The PostgreSQL Company - Command Prompt, Inc.



-- 
Albert Cervera i Areny
http://www.NaN-tic.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: Does anything dump per-database config settings? (was Re: [HACKERS] ALTER DATABASE vs pg_dump)

2008-08-22 Thread Bruce Momjian
Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
  ALTER DATABASE ... SET seems to be something that doesn't fit in
  anywhere;  I am thinking pg_dump -g should dump it.
 
 The upthread conclusion was that pg_dump -C should do it.
 I am not sure how you come to the conclusion that -g is an
 appropriate place, seeing that -g will not create the database(s)
 that it'd be trying to apply ALTER to.

Agreed, now that I see pg_dump -C.  I have added a TODO item:

Add:  Have pg_dump -C emit ALTER DATABASE ... SET commands after
database creation 

Does the documentation need to be updated beyond my changes from
yesterday?

-- 
  Bruce Momjian  [EMAIL PROTECTED]http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
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] Difference when using ZIC vs. Timezone Abbr - Bug? - SOLVED

2008-08-22 Thread Dave Witt

Ah.. my definition of MDT was flawed; thanks for the help!

Alvaro Herrera wrote:

Tom Lane wrote:
  

Dave Witt [EMAIL PROTECTED] writes:


These two queries produce different output, using version 8.3.3:
SELECT '2008-01-01 00:00:00+00'::timestamptz AT TIME ZONE 'MDT';
SELECT '2008-01-01 00:00:00+00'::timestamptz AT TIME ZONE 'America/Boise';
  

Why are you surprised?  Boise would've been on MST not MDT on that date.



i.e. try using MST7MDT instead, which behaves more sanely.

--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
  




Re: [HACKERS] [FINALLY] the TODO list has migrated to Wiki

2008-08-22 Thread Brendan Jurd
On Fri, Aug 22, 2008 at 10:10 AM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
 Alvaro Herrera escribió:

 They did not merge with the text, but they were not searchable.  May I
 suggest using the text [easy] and [done] instead?  That way, it is
 searchable, and they don't merge with the text.

 I just made this change.  What I now notice is that both markers are
 visually not very different.  I don't know if this is something worth
 fussing about.  (Maybe the addition of icons as Brendan was suggesting
 would be sufficient visual clue.)


Based on the feedback so far, I have tried for a best of both worlds
approach.  The markers now include icons, which gives us visual
distinctiveness, and I've abbreviated the labels to [D] and [E],
which makes it very easy to search.

I agreed with Bruce that it was a shame the markers bumped the actual
item text over to the right.  It looked uneven.  So I applied a bit of
CSS-fu and got the markers to appear to the left of the items.  They
now appear in a similar fashion to the bullets in an unordered list.

Cheers,
BJ

-- 
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: plan invalidation vs stored procedures

2008-08-22 Thread Decibel!

On Aug 20, 2008, at 9:18 AM, Tom Lane wrote:
However I have no hard evidence to back up drawing the line there  
rather

than somewhere else.  Anyone have data on what sort of DDL changes are
common in their applications?



I've worked in environments where we used stored functions  
extensively and where we didn't. Table DDL is generally fairly common  
in both cases, and if stored functions or views are used, it's very  
common for table DDL to trigger updates in views and functions. It's  
fairly common to have to update just functions to kill bugs or change  
functionality. Trigger changes are a bit less frequent, and views are  
probably the least frequent.

--
Decibel!, aka Jim C. Nasby, Database Architect  [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828




smime.p7s
Description: S/MIME cryptographic signature


Re: [HACKERS] Improving non-joinable EXISTS subqueries

2008-08-22 Thread Decibel!

On Aug 20, 2008, at 12:43 PM, Tom Lane wrote:

We have speculated in the past about having alternative plans that
could be conditionally executed based on information not available
at planning time.  This could be seen as a first experiment in that
direction.  I am not thinking of a general-purpose AlternativePlan
kind of execution node, because SubPlans aren't actually part of the
main plan-node tree, but an AlternativeSubPlans expression node
type might work.


Something I think we could also use is the ability to grab certain  
information before planing takes place. The big case that comes to  
mind is:


SELECT ... FROM big_table b JOIN small_lookup_table s USING  
(small_lookup_id)

WHERE s.some_name = 'alpha';

... or where we're doing s.some_name IN ('a','b','c'). In many cases,  
translating the some_name lookup into actual _id values that you can  
then look at in pg_stats for big_table results in a huge improvement  
is rowcount estimates. If this is then joining to 5 other tables,  
that rowcount information can have a huge impact on the query plan.



Another technique that we could play with is to have the
AlternativeSubPlans node track the actual number of calls it gets,
and switch from the retail implementation to the hashed
implementation if that exceeds a threshold.  This'd provide some
robustness in the face of bad estimates, although of course it's
not optimal compared to having made the right choice to start with.



In many systems, having the most optimal plan isn't that important;  
not having a really bad plan is. I expect that giving the executor  
the ability to decide the planner made a mistake and shift gears  
would go a long way to reducing the impact of bad plans. I wonder if  
any other databases have that ability... maybe this will be a first. :)

--
Decibel!, aka Jim C. Nasby, Database Architect  [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828




smime.p7s
Description: S/MIME cryptographic signature


Re: [HACKERS] [GENERAL] Surprising syntax error

2008-08-22 Thread Decibel!
Are we still tracking beginner TODOs separately? I'm thinking this  
falls into that category...


Barring objection, I'll mark it as easy.

On Aug 21, 2008, at 5:38 PM, Bruce Momjian wrote:



Added to TODO:

Allow GRANT/REVOKE on views to use the VIEW keyword rather
than just TABLE

http://archives.postgresql.org/pgsql-hackers/2008-06/msg01133.php


-- 
-


Bruce Momjian wrote:

Marc Munro wrote:
-- Start of PGP signed section.

The statement:

  revoke all on view internal.all_objects from public;

yields a syntax error.  The docs show that the word view is not
acceptable in this statement which is fine but the surprising  
thing is

that:

?  revoke all on table internal.all_objects from public;

works fine even though all_objects is a view and not a table.

Now that I know about it, this doesn't bother me but it was a  
surprise

and I wonder whether the the parser/planner/whatever should be a bit
smarter about allowing the word table to apply to non-tables, and
whether the word view ought to be allowed.


Yes, I can confirm this behavior on CVS HEAD, and it is odd:

test= CREATE SCHEMA internal;
CREATE SCHEMA
test= CREATE VIEW internal.all_objects AS SELECT 1;
CREATE VIEW
test= REVOKE ALL ON VIEW internal.all_objects FROM PUBLIC;
ERROR:  syntax ERROR AT OR near internal
LINE 1: REVOKE ALL ON VIEW internal.all_objects FROM PUBLIC;
   ^
test= REVOKE ALL ON TABLE internal.all_objects FROM PUBLIC;
REVOKE

Is there a downside to adding VIEW in parser/ 
gram.y:privilege_target?


--
  Bruce Momjian  [EMAIL PROTECTED]http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

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


--
  Bruce Momjian  [EMAIL PROTECTED]http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

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



--
Decibel!, aka Jim C. Nasby, Database Architect  [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828




smime.p7s
Description: S/MIME cryptographic signature


Re: [HACKERS] proposal sql: labeled function params

2008-08-22 Thread Decibel!

On Aug 20, 2008, at 8:26 AM, Pavel Stehule wrote:

2008/8/20 Tom Lane [EMAIL PROTECTED]:

Pavel Stehule [EMAIL PROTECTED] writes:
I understand now why Oracle use = symbol for named params. This  
isn't

used so operator - so implementation is trivial.


You really didn't understand the objection at all, did you?

The point is not about whether there is any built-in operator  
named =.
The point is that people might have created user-defined operators  
named

that.


I understand well, so only I don't see better solution. Yes, everyone
who used = should have problems, but it is similar with .. new
keywords, etc. Probably easy best syntax doesn't exist :(. I  haven't
idea who use = now and how often, and if this feature is possible in
pg, but there are not technical barriers.



How about we poll -general and see what people say? I'll bet Tom a  
beer that no one replies saying they've created a = operator (unless  
maybe PostGIS uses it).


If we're really worried about it we can have a GUC for a few versions  
that turns off named parameter assignment. But I don't think we  
should compromise the design on the theory that some folks might be  
using that as an operator *and* can't change their application to  
wrap it's use in ().

--
Decibel!, aka Jim C. Nasby, Database Architect  [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828




smime.p7s
Description: S/MIME cryptographic signature


Re: [HACKERS] [DOCS] [ADMIN] shared_buffers and shmmax

2008-08-22 Thread Decibel!

On Aug 12, 2008, at 2:43 PM, Greg Smith wrote:

On Tue, 12 Aug 2008, Bruce Momjian wrote:
There's already some changes needed in this area needed to  
execute the
full GUC cleanup/wizard plan that's being worked on.  The  
pg_settings view
really should show the value both as the user input it and as  
it's stored
internally for cases like these, which lowers the confusion here  
a bit

even without going so far as converting everything to bytes.


Is this a TODO?


I don't think you need yet another TODO for every detail, the  
existing TODO Add external tool to auto-tune some postgresql.conf  
parameters has to squash a bunch of issues in this area.  This  
particular issue Greg raised will already be improved significantly  
if executing the larger project plan at http://wiki.postgresql.org/ 
wiki/GUCS_Overhaul



Yeah, but OTOH it's not clear at all when we might see such a tool,  
while clarifying this stuff would help people immediately... I think  
a TODO would be good to make sure this doesn't fall through the cracks.

--
Decibel!, aka Jim C. Nasby, Database Architect  [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828




smime.p7s
Description: S/MIME cryptographic signature


Re: [HACKERS] [GENERAL] Surprising syntax error

2008-08-22 Thread Bruce Momjian
Decibel! wrote:
 Are we still tracking beginner TODOs separately? I'm thinking this  
 falls into that category...
 
 Barring objection, I'll mark it as easy.

I already had; markers just don't cust/paste easily like they used to.

-- 
  Bruce Momjian  [EMAIL PROTECTED]http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
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] [GENERAL] Surprising syntax error

2008-08-22 Thread Andrew Dunstan


depends if you think hacking the bison grammar is a beginner task.

cheers

andrew

Decibel! wrote:
Are we still tracking beginner TODOs separately? I'm thinking this 
falls into that category...


Barring objection, I'll mark it as easy.

On Aug 21, 2008, at 5:38 PM, Bruce Momjian wrote:



Added to TODO:

Allow GRANT/REVOKE on views to use the VIEW keyword rather
than just TABLE

http://archives.postgresql.org/pgsql-hackers/2008-06/msg01133.php


--- 



Bruce Momjian wrote:

Marc Munro wrote:
-- Start of PGP signed section.

The statement:

  revoke all on view internal.all_objects from public;

yields a syntax error.  The docs show that the word view is not
acceptable in this statement which is fine but the surprising thing is
that:

?  revoke all on table internal.all_objects from public;

works fine even though all_objects is a view and not a table.

Now that I know about it, this doesn't bother me but it was a surprise
and I wonder whether the the parser/planner/whatever should be a bit
smarter about allowing the word table to apply to non-tables, and
whether the word view ought to be allowed.


Yes, I can confirm this behavior on CVS HEAD, and it is odd:

test= CREATE SCHEMA internal;
CREATE SCHEMA
test= CREATE VIEW internal.all_objects AS SELECT 1;
CREATE VIEW
test= REVOKE ALL ON VIEW internal.all_objects FROM PUBLIC;
ERROR:  syntax ERROR AT OR near internal
LINE 1: REVOKE ALL ON VIEW internal.all_objects FROM PUBLIC;
   ^
test= REVOKE ALL ON TABLE internal.all_objects FROM PUBLIC;
REVOKE

Is there a downside to adding VIEW in parser/gram.y:privilege_target?

--  Bruce Momjian  [EMAIL PROTECTED]http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

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


--  Bruce Momjian  [EMAIL PROTECTED]http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

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



--Decibel!, aka Jim C. Nasby, Database Architect  [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828




--
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] Solaris ident authentication using unix domain sockets

2008-08-22 Thread Bruce Momjian
Garick Hamlin wrote:
 On Thu, Jul 03, 2008 at 02:01:22PM -0400, Tom Lane wrote:
  Garick Hamlin [EMAIL PROTECTED] writes:
 I have a patch that I have been using to support postgresql's
   notion of ident authentication when using unix domain sockets on
   Solaris.  This patch basically just adds support for using
   getupeercred() on Solaris so unix sockets and ident auth works just
   like it does on Linux and elsewhere.
  
  Cool.
  
   + #if defined(HAVE_GETPEERUCRED)
   + #include ucred.h
   + #endif
  
  But this is not cool.  There might be systems out there that have
  getpeerucred() but not ucred.h, and this coding would cause a compile
  failure (even if they actually wouldn't be trying to use getpeerucred()
  because they have some other way to do it).  You need an explicit
  configure probe for the header file too, I think.
 Ok, I can fix that.

Garick, have you made any progress on an updated patch?

-- 
  Bruce Momjian  [EMAIL PROTECTED]http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
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] [FINALLY] the TODO list has migrated to Wiki

2008-08-22 Thread Euler Taveira de Oliveira
Hi,

While we're on this topic, I think we need put a link at [1] heading
directly to (Official) Todo [2]. What we have ATM is Unofficial Todo
Detail that is rather inconsistent. We should rename it to Todo
Detail. Comments?

[1] http://wiki.postgresql.org/wiki/Development_information
[2] http://wiki.postgresql.org/wiki/Todo


-- 
  Euler Taveira de Oliveira
  http://www.timbira.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] [FINALLY] the TODO list has migrated to Wiki

2008-08-22 Thread Joshua Drake
On Fri, 22 Aug 2008 14:28:57 -0300
Euler Taveira de Oliveira [EMAIL PROTECTED] wrote:

 Hi,
 
 While we're on this topic, I think we need put a link at [1] heading
 directly to (Official) Todo [2]. What we have ATM is Unofficial Todo
 Detail that is rather inconsistent. We should rename it to Todo
 Detail. Comments?
 
 [1] http://wiki.postgresql.org/wiki/Development_information
 [2] http://wiki.postgresql.org/wiki/Todo
 
 

To my knowledge we do not have an Official Todo.

Joshua D. Drake

-- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate



-- 
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] [FINALLY] the TODO list has migrated to Wiki

2008-08-22 Thread Bruce Momjian
Euler Taveira de Oliveira wrote:
 Hi,
 
 While we're on this topic, I think we need put a link at [1] heading
 directly to (Official) Todo [2]. What we have ATM is Unofficial Todo
 Detail that is rather inconsistent. We should rename it to Todo
 Detail. Comments?
 
 [1] http://wiki.postgresql.org/wiki/Development_information
 [2] http://wiki.postgresql.org/wiki/Todo

Agreed, we used to have an official TODO.detail in CVS but that is gone
so I think removing the Unofficial word int he title makes sense.

-- 
  Bruce Momjian  [EMAIL PROTECTED]http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

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


[HACKERS] convertion from mySQL (mysql_fetch_row)

2008-08-22 Thread Masis, Alexander (US SSA)
People, 
I am converting  C++ code to Postgres.
Need help on how to deal with mysql_fetch_row, mysql_store_result
functions in Postgres? There should be some C/C++ code available for
these things, I hope.
Thanks,
Alex.


-- 
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] convertion from mySQL (mysql_fetch_row)

2008-08-22 Thread Merlin Moncure
On Fri, Aug 22, 2008 at 2:20 PM, Masis, Alexander (US SSA)
[EMAIL PROTECTED] wrote:
 People,
 I am converting  C++ code to Postgres.
 Need help on how to deal with mysql_fetch_row, mysql_store_result
 functions in Postgres? There should be some C/C++ code available for
 these things, I hope.
 Thanks,
 Alex.

http://www.postgresql.org/docs/8.3/interactive/libpq.html
in particular,
http://www.postgresql.org/docs/8.3/interactive/libpq-exec.html#LIBPQ-EXEC-SELECT-INFO

The libpq API is slightly thicker than mysql, which essentially
returns char ** for MYSQL_ROW.

With pg, you have a lot of flexibility with how you send queries,
parameterized, asynchronous, prepared, etc.  For starters though you
want to look at PQexec which maps to (iirc) mysql_real_query, more or
less.

libpq has very nice handling of binary data -- the protocol has
ability to send and receive blobs (and other things) without escaping
-- which is nice.

merlin

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


Re: [HACKERS] CREATE CAST too strict?

2008-08-22 Thread Bruce Momjian

Peter, have you completed this yet?

---

Peter Eisentraut wrote:
 Am Mittwoch, 9. Juli 2008 schrieb Peter Eisentraut:
  I propose that we relax these two checks to test for binary-coercibility
  instead, which is effectively what is expected and required here anyway.
 
 Here is the corresponding patch.

[ Attachment, skipping... ]

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

-- 
  Bruce Momjian  [EMAIL PROTECTED]http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
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] [GENERAL] Surprising syntax error

2008-08-22 Thread Hannu Krosing
On Fri, 2008-08-22 at 12:42 -0400, Andrew Dunstan wrote:
 depends if you think hacking the bison grammar is a beginner task.

It may be anything from beginners task to quite complex . Some things
are just copypaste.

-
Hannu



-- 
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] proposal sql: labeled function params

2008-08-22 Thread Hannu Krosing
On Thu, 2008-08-21 at 23:41 -0500, Decibel! wrote:
 On Aug 20, 2008, at 8:26 AM, Pavel Stehule wrote:

 How about we poll -general and see what people say? I'll bet Tom a  
 beer that no one replies saying they've created a = operator (unless  
 maybe PostGIS uses it).

Does Oracle use = for labeled function params or just named
arguments ?

 If we're really worried about it we can have a GUC for a few versions  
 that turns off named parameter assignment. But I don't think we  
 should compromise the design on the theory that some folks might be  
 using that as an operator *and* can't change their application to  
 wrap it's use in ().

I still think that better approach is allowing RECORD as input type and
do all the things Pavel proposed with a function that iterates over
record.

--
Hannu



-- 
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] proposal sql: labeled function params

2008-08-22 Thread Teodor Sigaev
How about we poll -general and see what people say? I'll bet Tom a  
beer that no one replies saying they've created a = operator (unless  
maybe PostGIS uses it).

Hstore uses it:
   * text = text - creates hstore type from two text strings

select 'a'='b';
  ?column?
--
  a=b


--
Teodor Sigaev   E-mail: [EMAIL PROTECTED]
   WWW: http://www.sigaev.ru/

--
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] Feeding results back into select (was: proposal sql: labeled function params)

2008-08-22 Thread D'Arcy J.M. Cain
On Sat, 23 Aug 2008 00:03:16 +0400
Teodor Sigaev [EMAIL PROTECTED] wrote:
 select 'a'='b';
?column?
 --
a=b

Branching the topic, I have a question about this.  I haven't studied
hstore extensively but this seems like a problem on it's face.
Shouldn't you be able to take the result of a select and pass it back
to a select?  I mean, what happens if you do this?

select a=b;

I suspect that you would get ERROR:  column a does not exist if you
do that.  What happens when you try to restore a dump?

I ran into a similar issue with my chkpass type (see contrib) where the
string inserted into the field is stored encrypted with functions to
test for equality basically like the Unix password model works.  If I
just displayed raw strings then a dump and reload would have trashed
all the passwords by re-encrypting them.  What I did was to make a
special case on input.  If the string started with ':' then I strip
that character and insert the string unchanged.  Then I changed the
output to prepend the ':'.  Now dump and reload work.

Just curious.

-- 
D'Arcy J.M. Cain [EMAIL PROTECTED] |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.

-- 
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] WITH RECURSIVE patches 0818

2008-08-22 Thread Tatsuo Ishii
 I think I may have found another bug:
 
 WITH RECURSIVE t(i,j) AS (
 VALUES (1,2)
 UNION ALL
 SELECT t2.i, t.j
 FROM (
 SELECT 2 AS i
 UNION ALL   /* Wrongly getting detected, I think */
 SELECT 3 AS i
 ) AS t2
 JOIN
 t
 ON (t2.i = t.i)
 )
 SELECT * FROM t;
 ERROR:  attribute number 2 exceeds number of columns 1
 
 Is there some way to ensure that in the case of WITH RECURSIVE, the
 query to the right of UNION ALL follows only the SQL:2008 rules about
 not having outer JOINs, etc. in it, but otherwise make it opaque to
 the error-checking code?
 
 I know I didn't explain that well, but the above SQL should work and
 the error appears to stem from the parser's looking at the innermost
 UNION ALL instead of the outermost.

Here is new patches fixing the bug you pointed out (patches was
created by Yoshiyuki). Also I added your SQL to the regression test,
and now the patches is against CVS HEAD. For your convenience I also
include patches against the previous version.
--
Tatsuo Ishii
SRA OSS, Inc. Japan


recursive_query.patch.gz
Description: Binary data
*** pgsql/src/backend/executor/nodeAppend.c 2008-08-18 16:20:40.0 
+0900
--- pgsql.patched/src/backend/executor/nodeAppend.c 2008-08-23 
07:37:29.0 +0900
***
*** 143,152 
--- 143,156 
int nplans;
int i;
Plan   *initNode;
+   TupleDesc  save_tupledesc;
  
/* check for unsupported flags */
Assert(!(eflags  EXEC_FLAG_MARK));
  
+   /* Save tuple desc */
+   save_tupledesc = estate-es_rscan_tupledesc;
+ 
/*
 * Set up empty vector of subplan states
 */
***
*** 232,237 
--- 236,243 
appendstate-as_whichplan = appendstate-as_firstplan;
exec_append_initialize_next(appendstate);
  
+   /* Restore tuple desc */
+   estate-es_rscan_tupledesc = save_tupledesc;
+ 
return appendstate;
  }

-- 
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] Extending grant insert on tables to sequences

2008-08-22 Thread Bruce Momjian

Added to September commit fest.

---

Abhijit Menon-Sen wrote:
 At 2008-07-09 15:11:25 -0400, [EMAIL PROTECTED] wrote:
 
  No, actually I meant having a lone list = lappend(list, newseq); in
  the loop, so that ExecGrantStmt_oids is called only once.
 
 Yes, I understand what you meant. I just phrased my agreement poorly.
 Here's a more precise phrasing. ;-)
 
 (I agree with Robert Treat that there seems to be no point granting
 SELECT on the sequence. I don't *particularly* care about it, but I
 tend towards wanting to drop that bit. This patch reflects that.)
 
 Jaime: please feel free to use or ignore this, as you wish.
 
 -- ams
 
 diff --git a/src/backend/catalog/aclchk.c b/src/backend/catalog/aclchk.c
 index 15f5af0..8664203 100644
 --- a/src/backend/catalog/aclchk.c
 +++ b/src/backend/catalog/aclchk.c
 @@ -361,6 +361,41 @@ ExecuteGrantStmt(GrantStmt *stmt)
   }
  
   ExecGrantStmt_oids(istmt);
 +
 + /* If INSERT or UPDATE privileges are being granted or revoked on a
 +  * relation, this extends the operation to include any sequences
 +  * owned by the relation.
 +  */
 +
 + if (istmt.objtype == ACL_OBJECT_RELATION 
 + (istmt.privileges  (ACL_INSERT | ACL_UPDATE)))
 + {
 + InternalGrant istmt_seq;
 +
 + istmt_seq.is_grant = istmt.is_grant;
 + istmt_seq.objtype = ACL_OBJECT_SEQUENCE;
 + istmt_seq.grantees = istmt.grantees;
 + istmt_seq.grant_option = istmt.grant_option;
 + istmt_seq.behavior = istmt.behavior;
 + istmt_seq.all_privs = false;
 +
 + istmt_seq.privileges = ACL_NO_RIGHTS;
 + if (istmt.privileges  ACL_INSERT)
 + istmt_seq.privileges |= ACL_USAGE;
 + if (istmt.privileges  ACL_UPDATE)
 + istmt_seq.privileges |= ACL_UPDATE;
 +
 + istmt_seq.objects = NIL;
 + foreach (cell, istmt.objects)
 + {
 + istmt_seq.objects =
 + list_concat(istmt_seq.objects,
 + 
 getOwnedSequences(lfirst_oid(cell)));
 + }
 +
 + if (istmt_seq.objects != NIL)
 + ExecGrantStmt_oids(istmt_seq);
 + }
  }
  
  /*
 
 -- 
 Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-hackers

-- 
  Bruce Momjian  [EMAIL PROTECTED]http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
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] [PATCHES] VACUUM Improvements - WIP Patch

2008-08-22 Thread Bruce Momjian

I assume there is no TODO here.

---

Pavan Deolasee wrote:
 (taking the discussions to -hackers)
 
 On Sat, Jul 12, 2008 at 11:02 PM, Tom Lane [EMAIL PROTECTED] wrote:
 
 
  (2) It achieves speedup of VACUUM by pushing work onto subsequent
  regular accesses of the page, which is exactly the wrong thing.
  Worse, once you count the disk writes those accesses will induce it's
  not even clear that there's any genuine savings.
 
 
 Well in the worst case that is true. But in most other cases, the
 second pass work will be combined with other normal activities and the
 overhead will be shared, at least there is a chance for that. I think
 there is a chance for delaying the work until there is any real need
 for that e.g. INSERT or UPDATE on the page which would require a free
 line pointer.
 
 
  (3) The fact that it doesn't work until concurrent transactions have
  gone away makes it of extremely dubious value in real-world scenarios,
  as already noted by Simon.
 
 
 If there are indeed long running concurrent transactions, we won't get
 any benefit of this optimization. But then there are several more
 common cases of very short concurrent transactions. In those cases and
 for very large tables, reducing the vacuum time is a significant win.
 The FSM will be written early and significant work of the VACUUM can
 be finished quickly.
 
  It strikes me that what you are trying to do here is compensate for
  a bad decision in the HOT patch, which was to have VACUUM's first
  pass prune/defrag a page even when we know we are going to have to
  come back to that page later.  What about trying to fix things so
  that if the page contains line pointers that need to be removed,
  the first pass doesn't dirty it at all, but leaves all the work
  to be done at the second visit?  I think that since heap_page_prune
  has been refactored into a scan followed by an apply, it'd be
  possible to decide before the apply step whether this is the case
  or not.
 
 
 I am not against this idea. Just that it still requires us double scan
 of the main table and that's exactly what we are trying to avoid with
 this patch.
 
 Thanks,
 Pavan
 
 -- 
 Pavan Deolasee
 EnterpriseDB http://www.enterprisedb.com
 
 -- 
 Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-hackers

-- 
  Bruce Momjian  [EMAIL PROTECTED]http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

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