Re: [HACKERS] Help needed for PL/Ruby

2015-05-01 Thread Szymon Guz
On 29 April 2015 at 21:45, Szymon Guz mabew...@gmail.com wrote:

 Hi Devrim,
 I will take a look at this.

 regards,
 Szymon

 On 29 April 2015 at 18:24, Devrim Gündüz dev...@gunduz.org wrote:


 Hi,

 Anyone? :)

 Regards, Devrim

 On Wed, 2015-03-18 at 15:19 +0200, Devrim Gündüz wrote:
  Hi,
 
  Background info first: PL/Ruby was originally maintained by Guy Decoux,
  who passed away in 2008: https://www.ruby-forum.com/topic/166658 .
 After
  his death, Akinori MUSHA forked the project and maintained it until
  2010: https://github.com/knu/postgresql-plruby . Last release was on
 Jan
  2010, and recent distros started throwing build errors.
 
  I was having similar build issues while trying to RPMify PL/Ruby, and
  finally stepped up the plate and tried to fix those build issues by
  forking the project:
 
  https://github.com/devrimgunduz/postgresql-plruby/
 
  I mainly applied patches from Fedora, and also did some basic cleanup.
  However, I don't know Ruby and have limited C skills, so I need some
  help on these:
 
  * Complete the extension support: I committed initial infrastructure for
  it, but I don't think it is ready yet.
 
  * Fix the FIXME:
 
 https://github.com/devrimgunduz/postgresql-plruby/blob/master/src/plpl.c#L844
 
  * Documentation review and update: The recent example is against
  PostgreSQL 8.0. A recent Ruby example would be good, and also we need
  updates for creating the language.
 
  Any contributions are welcome. I recently released 0.5.5 that at least
  is ready for testing.
 
  I want to remind that I am not a Ruby guy, so this is really a community
  stuff for me.
 
  Thanks by now.
 
  Regards,


 --
 Devrim GÜNDÜZ
 Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
 PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
 Twitter: @DevrimGunduz , @DevrimGunduzTR





Hi Devrim,
I checked the code, and it seems like there is a lot of work to make this
plruby stuff working with the new postgres.

I think we need to get rid of the code for supporting the older postgres
versions than 8.4. Or even 9.0 (if there is any code for that) as this
version get obsolete in September this year, and I'm sure that I'm alone
will not be able to make all the changes till that time.

Compiling the code gives me lots of warnings, which also should be cleared.

The previous release was made long time ago, so it is not up to date with
the last postgres changes - a lot of work too.

So, I will work on it, however fixing and updating the code will take some
time.

Oh, and documentation of course.

At this moment I will do all the work on my github account.

regards,
Szymon


Re: [HACKERS] printing table in asciidoc with psql

2014-11-14 Thread Szymon Guz
On 14 November 2014 20:57, Alvaro Herrera alvhe...@2ndquadrant.com wrote:

 Is anyone going to submit a new version of this patch?




Hi Alvaro,
due to family issues I will not be able to work on it for the next 10 days.

regards,
Szymon


Re: [HACKERS] printing table in asciidoc with psql

2014-10-30 Thread Szymon Guz
On 30 October 2014 09:04, Pavel Stehule pavel.steh...@gmail.com wrote:



 2014-10-29 12:23 GMT+01:00 Szymon Guz mabew...@gmail.com:



 On 17 October 2014 09:01, Pavel Stehule pavel.steh...@gmail.com wrote:

 Hi Szymon

 I found a small bug - it doesn't escape | well

 postgres=# select * from mytab ;
 a | numeric_b | c
 --+---+
  Ahoj |10 | 2014-10-17
  Hello|20 | 2014-10-18
  Hi   |30 | 2014-10-19
  aaa| |   | 2014-10-17
 (4 rows)

 result


 [options=header,cols=literal,literal,literal,frame=all,grid=all]
 |
 ^| +++a+++ ^| +++numeric_b+++ ^| +++c+++
 | Ahoj | 10 | 2014-10-17
 | Hello | 20 | 2014-10-18
 | Hi | 30 | 2014-10-19
 | aaa| |  | 2014-10-17
 |


 Next, I tested it with asciidoc and asciidoctor and I have a problem
 with asciidoctor - it doesn't respect aligning .. so numbers are aligned to
 left instead to right.

 When you use a option header then a formatting +++ is
 useless.


 Hi Pavel,
 thanks for the remarks. I've attached another version of the pach. It
 works a little better now, including escaping | and asciidoctor alignment
 support.


 it is fixed. Thank you.

 I fixed formatting - please, recheck it.

 I don't see any issue - it should be ready for commiter

 Regards

 Pavel



Hi Pavel,
thanks for the review and reformatting. It looks much better after the
reformatting.

thanks,
Szymon


Re: [HACKERS] printing table in asciidoc with psql

2014-10-29 Thread Szymon Guz
On 17 October 2014 09:01, Pavel Stehule pavel.steh...@gmail.com wrote:

 Hi Szymon

 I found a small bug - it doesn't escape | well

 postgres=# select * from mytab ;
 a | numeric_b | c
 --+---+
  Ahoj |10 | 2014-10-17
  Hello|20 | 2014-10-18
  Hi   |30 | 2014-10-19
  aaa| |   | 2014-10-17
 (4 rows)

 result

 [options=header,cols=literal,literal,literal,frame=all,grid=all]
 |
 ^| +++a+++ ^| +++numeric_b+++ ^| +++c+++
 | Ahoj | 10 | 2014-10-17
 | Hello | 20 | 2014-10-18
 | Hi | 30 | 2014-10-19
 | aaa| |  | 2014-10-17
 |


 Next, I tested it with asciidoc and asciidoctor and I have a problem with
 asciidoctor - it doesn't respect aligning .. so numbers are aligned to left
 instead to right.

 When you use a option header then a formatting +++ is useless.


Hi Pavel,
thanks for the remarks. I've attached another version of the pach. It works
a little better now, including escaping | and asciidoctor alignment support.

thanks,
Szymon
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index e7fcc73..cd64b88 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -2092,8 +2092,8 @@ lo_import 152801
   literalaligned/literal, literalwrapped/literal,
   literalhtml/literal,
   literallatex/literal (uses literaltabular/literal),
-  literallatex-longtable/literal, or
-  literaltroff-ms/literal.
+  literallatex-longtable/literal,
+  literaltroff-ms/literal, or literalasciidoc/literal.
   Unique abbreviations are allowed.  (That would mean one letter
   is enough.)
   /para
@@ -2120,7 +2120,8 @@ lo_import 152801
 
   para
   The literalhtml/, literallatex/,
-  literallatex-longtable/literal, and literaltroff-ms/
+  literallatex-longtable/literal, literaltroff-ms/,
+  and literalasciidoc/
   formats put out tables that are intended to
   be included in documents using the respective mark-up
   language. They are not complete documents! This might not be
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 26089352..e00e47b 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -2248,6 +2248,9 @@ _align2string(enum printFormat in)
 		case PRINT_TROFF_MS:
 			return troff-ms;
 			break;
+		case PRINT_ASCIIDOC:
+			return asciidoc;
+			break;
 	}
 	return unknown;
 }
@@ -2321,9 +2324,11 @@ do_pset(const char *param, const char *value, printQueryOpt *popt, bool quiet)
 			popt-topt.format = PRINT_LATEX_LONGTABLE;
 		else if (pg_strncasecmp(troff-ms, value, vallen) == 0)
 			popt-topt.format = PRINT_TROFF_MS;
+		else if (pg_strncasecmp(asciidoc, value, vallen) == 0)
+			popt-topt.format = PRINT_ASCIIDOC;
 		else
 		{
-			psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms\n);
+			psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms, asciidoc\n);
 			return false;
 		}
 
diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
index ae5fe88..b14b313 100644
--- a/src/bin/psql/help.c
+++ b/src/bin/psql/help.c
@@ -351,7 +351,7 @@ helpVariables(unsigned short int pager)
 	fprintf(output, _(  expanded (or x)toggle expanded output\n));
 	fprintf(output, _(  fieldsep   field separator for unaligned output (default '|')\n));
 	fprintf(output, _(  fieldsep_zero  set field separator in unaligned mode to zero\n));
-	fprintf(output, _(  format set output format [unaligned, aligned, wrapped, html, latex, ..]\n));
+	fprintf(output, _(  format set output format [unaligned, aligned, wrapped, html, latex, asciidoc ..]\n));
 	fprintf(output, _(  footer enable or disable display of the table footer [on, off]\n));
 	fprintf(output, _(  linestyle  set the border line drawing style [ascii, old-ascii, unicode]\n));
 	fprintf(output, _(  null   set the string to be printed in place of a null value\n));
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 3b3c3b7..83f268a 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -2475,6 +2475,217 @@ print_troff_ms_vertical(const printTableContent *cont, FILE *fout)
 	}
 }
 
+/*/
+/* ASCIIDOC **/
+/*/
+
+static void
+asciidoc_escaped_print(const char *in, FILE *fout)
+{
+  const char *p;
+  for (p = in; *p; p++)
+  {
+switch(*p)
+{
+  case '|':
+fputs(\\|, fout);
+break;
+  default:
+fputc(*p, fout);
+}
+  }
+}
+
+static void
+print_asciidoc_text(const printTableContent *cont, FILE *fout)
+{
+	bool		opt_tuples_only = cont-opt-tuples_only;
+	unsigned short opt_border = cont-opt-border;
+	unsigned int i;
+	const char *const * ptr;
+
+	if (cancel_pressed)
+		return;
+
+	if (cont-opt-start_table)
+	{
+		/* print title */
+		

Re: [HACKERS] printing table in asciidoc with psql

2014-09-17 Thread Szymon Guz
On 17 September 2014 19:30, Peter Eisentraut pete...@gmx.net wrote:

 On 9/16/14 3:52 PM, Szymon Guz wrote:
  It's not finished yet, I'm not sure it there is any sense in supporting
  border types etc.

 AFAICT, Asciidoc doesn't support border types, so (if so) you should
 just ignore that setting.


Too late, I've done something like this:

border=0
[frame=none,grid=none]

border=1
[frame=all,grid=none]

border=2
[frame=all,grid=all]

thanks,
Szymon


Re: [HACKERS] printing table in asciidoc with psql

2014-09-17 Thread Szymon Guz
On 17 September 2014 19:55, Szymon Guz mabew...@gmail.com wrote:



 On 17 September 2014 19:30, Peter Eisentraut pete...@gmx.net wrote:

 On 9/16/14 3:52 PM, Szymon Guz wrote:
  It's not finished yet, I'm not sure it there is any sense in supporting
  border types etc.

 AFAICT, Asciidoc doesn't support border types, so (if so) you should
 just ignore that setting.


 Too late, I've done something like this:

 border=0
 [frame=none,grid=none]

 border=1
 [frame=all,grid=none]

 border=2
 [frame=all,grid=all]

 thanks,
 Szymon



Hi,
thanks for all the remarks.

I've attached another version of this patch.

I think it's done.

- This works: `\pset format asciidoc`

- Output is formatted as asciidoc tables.

- There is support for borders {0,1,2}. The attached html file was made by
running tests for psql, taking the asciidoc tables from it, converting to
html with `asciidoc file`.
-- border = 0 - [frame=none,grid=none]
-- border = 1 - [frame=none,grid=all]
-- border = 2 - [frame=all,grid=all]

- There are also tests.
-- For normal and extended mode combined with each of the border values.
-- With column names made of characters which need escaping
-- With values: (with escape needed characters, string '11' and integer 11
- they should have different right-left alignment).

- Documentation for psql is updated.

- According to Emanuel's advice: help.c is updated.

The attached html file contains tables from the test in this order:

normal, border 0
normal, border 1
normal, border 2
expanded, border 0
expanded, border 1
expanded, border 2

regards,
Szymon
 text/html; charset=US-ASCII; name="asciidoc_output.html": Unrecognized 
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index e7fcc73..cd64b88 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -2092,8 +2092,8 @@ lo_import 152801
   literalaligned/literal, literalwrapped/literal,
   literalhtml/literal,
   literallatex/literal (uses literaltabular/literal),
-  literallatex-longtable/literal, or
-  literaltroff-ms/literal.
+  literallatex-longtable/literal,
+  literaltroff-ms/literal, or literalasciidoc/literal.
   Unique abbreviations are allowed.  (That would mean one letter
   is enough.)
   /para
@@ -2120,7 +2120,8 @@ lo_import 152801
 
   para
   The literalhtml/, literallatex/,
-  literallatex-longtable/literal, and literaltroff-ms/
+  literallatex-longtable/literal, literaltroff-ms/,
+  and literalasciidoc/
   formats put out tables that are intended to
   be included in documents using the respective mark-up
   language. They are not complete documents! This might not be
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 2227db4..ae6b106 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -2247,6 +2247,9 @@ _align2string(enum printFormat in)
 		case PRINT_TROFF_MS:
 			return troff-ms;
 			break;
+		case PRINT_ASCIIDOC:
+			return asciidoc;
+			break;
 	}
 	return unknown;
 }
@@ -2316,9 +2319,11 @@ do_pset(const char *param, const char *value, printQueryOpt *popt, bool quiet)
 			popt-topt.format = PRINT_LATEX_LONGTABLE;
 		else if (pg_strncasecmp(troff-ms, value, vallen) == 0)
 			popt-topt.format = PRINT_TROFF_MS;
+		else if (pg_strncasecmp(asciidoc, value, vallen) == 0)
+			popt-topt.format = PRINT_ASCIIDOC;
 		else
 		{
-			psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms\n);
+			psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms, asciidoc\n);
 			return false;
 		}
 
diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
index 6035a77..66da6ec 100644
--- a/src/bin/psql/help.c
+++ b/src/bin/psql/help.c
@@ -351,7 +351,7 @@ helpVariables(unsigned short int pager)
 	fprintf(output, _(  expanded (or x)toggle expanded output\n));
 	fprintf(output, _(  fieldsep   field separator for unaligned output (default '|')\n));
 	fprintf(output, _(  fieldsep_zero  set field separator in unaligned mode to zero\n));
-	fprintf(output, _(  format set output format [unaligned, aligned, wrapped, html, latex, ..]\n));
+	fprintf(output, _(  format set output format [unaligned, aligned, wrapped, html, latex, asciidoc ..]\n));
 	fprintf(output, _(  footer enable or disable display of the table footer [on, off]\n));
 	fprintf(output, _(  linestyle  set the border line drawing style [ascii, old-ascii, unicode]\n));
 	fprintf(output, _(  null   set the string to be printed in place of a null value\n));
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 3b3c3b7..956bbb1 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -2475,6 +2475,200 @@ print_troff_ms_vertical(const printTableContent *cont, FILE *fout)
 	}
 }
 
+/*/
+/

[HACKERS] printing table in asciidoc with psql

2014-09-16 Thread Szymon Guz
Hi,
I've been working a little bit on a patch for printing tables in asciidoc
with psql.

It's not finished yet, I'm not sure it there is any sense in supporting
border types etc. The code is not cleared so far, but any remarks on the
style not playing well with the normal postgres style of code are welcomed.

The code just works. With extended and normal modes. With table columns
made of funny characters, with alignment of data in table cells. I was
trying to implement it similar to the html export function, however
escaping of the strings was much easier, as the normal html-way
substitution is not easy to implement in asciidoc.

I'd like to ask you for any advices for this code.

thanks,
Szymon
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 2227db4..ae6b106 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -2247,6 +2247,9 @@ _align2string(enum printFormat in)
 		case PRINT_TROFF_MS:
 			return troff-ms;
 			break;
+		case PRINT_ASCIIDOC:
+			return asciidoc;
+			break;
 	}
 	return unknown;
 }
@@ -2316,9 +2319,11 @@ do_pset(const char *param, const char *value, printQueryOpt *popt, bool quiet)
 			popt-topt.format = PRINT_LATEX_LONGTABLE;
 		else if (pg_strncasecmp(troff-ms, value, vallen) == 0)
 			popt-topt.format = PRINT_TROFF_MS;
+		else if (pg_strncasecmp(asciidoc, value, vallen) == 0)
+			popt-topt.format = PRINT_ASCIIDOC;
 		else
 		{
-			psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms\n);
+			psql_error(\\pset: allowed formats are unaligned, aligned, wrapped, html, latex, troff-ms, asciidoc\n);
 			return false;
 		}
 
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
index 3b3c3b7..236c8f3 100644
--- a/src/bin/psql/print.c
+++ b/src/bin/psql/print.c
@@ -2475,6 +2475,180 @@ print_troff_ms_vertical(const printTableContent *cont, FILE *fout)
 	}
 }
 
+/*/
+/* ASCIIDOC **/
+/*/
+
+static void
+print_asciidoc_text(const printTableContent *cont, FILE *fout)
+{
+	bool		opt_tuples_only = cont-opt-tuples_only;
+	unsigned int i;
+	const char *const * ptr;
+
+	if (cancel_pressed)
+		return;
+
+	if (cont-opt-start_table)
+	{
+		/* print title */
+		if (!opt_tuples_only  cont-title)
+		{
+  fputs(., fout);
+			fputs(cont-title, fout);
+  fputs(\n, fout);
+		}
+
+/* print table [] header definition */
+		fprintf(fout, [options=\header\,cols=\);
+for(i = 0; i  cont-ncolumns; i++) {
+  if (i != 0) fputs(,, fout);
+		  fprintf(fout, %s, cont-aligns[(i) % cont-ncolumns] == 'r' ? literal : literal);
+}
+fprintf(fout, \]\n);
+		fprintf(fout, |\n);
+
+		/* print headers */
+		if (!opt_tuples_only)
+		{
+			for (ptr = cont-headers; *ptr; ptr++)
+			{
+fputs(^| +++, fout);
+fputs(*ptr, fout);
+fputs(+++ , fout);
+			}
+			fputs(\n, fout);
+		}
+	}
+
+	/* print cells */
+	for (i = 0, ptr = cont-cells; *ptr; i++, ptr++)
+	{
+		if (i % cont-ncolumns == 0)
+		{
+			if (cancel_pressed)
+break;
+}
+		
+fprintf(fout, | );
+
+		if ((*ptr)[strspn(*ptr,  \t)] == '\0')
+			fputs( , fout);
+		else
+			fputs(*ptr, fout);
+
+		fputs( , fout);
+
+		if ((i + 1) % cont-ncolumns == 0)
+			fputs(\n, fout);
+		
+
+	}
+  
+  fprintf(fout, |\n);
+
+	if (cont-opt-stop_table)
+	{
+		printTableFooter *footers = footers_with_default(cont);
+
+		/* print footers */
+		if (!opt_tuples_only  footers != NULL  !cancel_pressed)
+		{
+			printTableFooter *f;
+
+			fputs(\n\n, fout);
+			for (f = footers; f; f = f-next)
+			{
+fputs(f-data, fout);
+fputs(\n, fout);
+			}
+			fputs(\n, fout);
+		}
+
+	}
+}
+
+// TODO add support for cont-opt-border
+// TODO add support for additional options
+
+static void
+print_asciidoc_vertical(const printTableContent *cont, FILE *fout)
+{
+	bool		opt_tuples_only = cont-opt-tuples_only;
+	unsigned short opt_border = cont-opt-border;
+	const char *opt_table_attr = cont-opt-tableAttr;
+	unsigned long record = cont-opt-prior_records + 1;
+	unsigned int i;
+	const char *const * ptr;
+
+	if (cancel_pressed)
+		return;
+
+	if (cont-opt-start_table)
+	{
+		/* print title */
+		if (!opt_tuples_only  cont-title)
+		{
+  fputs(., fout);
+			fputs(cont-title, fout);
+  fputs(\n, fout);
+		}
+
+/* print table [] header definition */
+	  fprintf(fout, [cols=\h,literal\]\n);
+		fprintf(fout, |\n);
+
+	}
+
+	/* print records */
+	for (i = 0, ptr = cont-cells; *ptr; i++, ptr++)
+	{
+		if (i % cont-ncolumns == 0)
+		{
+			if (cancel_pressed)
+break;
+			if (!opt_tuples_only)
+fprintf(fout,
+		2+^| Record %lu\n,
+		record++);
+			else
+fputs(2| \n, fout);
+		}
+
+fputs(|+++, fout);
+		fputs(cont-headers[i % cont-ncolumns], fout);
+fputs(+++, fout);
+
+		fprintf(fout,  %s|, cont-aligns[i % cont-ncolumns] == 'r' ?  : );
+		/* is string only whitespace? */
+		if ((*ptr)[strspn(*ptr,  \t)] == '\0')
+			fputs( , fout);
+		else
+			fputs(*ptr, fout);
+
+		fputs(\n, 

Re: [HACKERS] PL/pgSQL 2

2014-09-03 Thread Szymon Guz
On 3 September 2014 01:08, Jan Wieck j...@wi3ck.info wrote:

 On 09/02/2014 06:56 PM, Andrew Dunstan wrote:

 People are free to do what they want, but to my mind that would be a
 massive waste of resources, and probably imposing a substantial extra
 maintenance burden on the core committers.


 I hear you and agree to some degree.

 But at the same time I remember that one of the strengths of Postgres used
 to be to be able to incorporate new ideas.

 This seems to be one of those cases.

 Instead of fork plpgsql2, what about designing a completely new
 PL/postgres from scratch? It will only take 3-10 years, but I bet it will
 be worth it after all. And I mean that. No sarcasm.


And how it would be better then already existing plperl/plpython?

- Szymon


[HACKERS] potential bug in psql

2014-08-22 Thread Szymon Guz
Hi,
when I run `\s` in psql, I get the nice list of queries with an error at
the end:

\s
could not save history to file /dev/tty: No such file or directory


Newest ubuntu from trunk

 PostgreSQL 9.5devel on x86_64-unknown-linux-gnu, compiled by Ubuntu clang
version 3.4-1ubuntu3 (tags/RELEASE_34/final) (based on LLVM 3.4), 64-bit

and zsh as shell

thanks,
Szymon


Re: [HACKERS] potential bug in psql

2014-08-22 Thread Szymon Guz
On 22 August 2014 17:06, Tom Lane t...@sss.pgh.pa.us wrote:

 Szymon Guz mabew...@gmail.com writes:
  when I run `\s` in psql, I get the nice list of queries with an error at
  the end:

  \s
  could not save history to file /dev/tty: No such file or directory

 Well, that's interesting ... what version of which readline library are
 you using?


Hi Tom,
that's libreadline6 from Ubuntu package 6.3-4ubuntu2


thanks,
Szymon


Re: [HACKERS] Storing the password in .pgpass file in an encrypted format

2014-02-21 Thread Szymon Guz
On 21 February 2014 13:49, firoz e v firoz...@huawei.com wrote:

  Hi,



 Is there a way to store the password in “.pgpass” file in an encrypted
 format (for example, to be used by pg_dump).



 Even though, there are ways to set the permissions on .pgpass, to disallow
 any access to world or group, the security rules of many organizations
 disallow to hold any kind of passwords, as plain text.



 If there is no existing way to do this, shall we take up this, as a patch?



 Regards,

 Firoz EV




And where are you going to keep the passwords to decrypt these passwords
(for example to be used by pg_dump)?

regards,
Szymon


Re: [HACKERS] new unicode table border styles for psql

2013-11-21 Thread Szymon Guz
On 21 November 2013 08:09, Pavel Stehule pavel.steh...@gmail.com wrote:

 Hello

 I wrote new styles for  psql table borders.

 http://postgres.cz/wiki/Pretty_borders_in_psql

 This patch is simply and I am think so some styles can be interesting for
 final presentation.

 Do you think so this feature is generally interesting and should be in
 core?

 Regards

 Pavel


YES!

- Szymon


Re: [HACKERS] new unicode table border styles for psql

2013-11-21 Thread Szymon Guz
On 21 November 2013 20:20, Pavel Stehule pavel.steh...@gmail.com wrote:

 So here is patch for 9.4

 7 new line styles, 2 new border styles, \pset border autocomplete

 Regards

 Pavel




 2013/11/21 Szymon Guz mabew...@gmail.com

 On 21 November 2013 08:09, Pavel Stehule pavel.steh...@gmail.com wrote:

 Hello

 I wrote new styles for  psql table borders.

 http://postgres.cz/wiki/Pretty_borders_in_psql

 This patch is simply and I am think so some styles can be interesting
 for final presentation.

 Do you think so this feature is generally interesting and should be in
 core?

 Regards

 Pavel


 YES!

 - Szymon



That's pretty cool, I'd love to see it in the core, however it doesn't
contain any documentation, so I'm afraid it will be hard to use for people.

thanks,
Szymon


Re: [HACKERS] new unicode table border styles for psql

2013-11-21 Thread Szymon Guz
On 21 November 2013 21:15, Szymon Guz mabew...@gmail.com wrote:




 On 21 November 2013 20:20, Pavel Stehule pavel.steh...@gmail.com wrote:

 So here is patch for 9.4

 7 new line styles, 2 new border styles, \pset border autocomplete

 Regards

 Pavel




 2013/11/21 Szymon Guz mabew...@gmail.com

 On 21 November 2013 08:09, Pavel Stehule pavel.steh...@gmail.comwrote:

 Hello

 I wrote new styles for  psql table borders.

 http://postgres.cz/wiki/Pretty_borders_in_psql

 This patch is simply and I am think so some styles can be interesting
 for final presentation.

 Do you think so this feature is generally interesting and should be in
 core?

 Regards

 Pavel


 YES!

 - Szymon



 That's pretty cool, I'd love to see it in the core, however it doesn't
 contain any documentation, so I'm afraid it will be hard to use for people.

 thanks,
 Szymon


Hi Pavel,
I've found two errors in the documentation at
http://postgres.cz/wiki/Pretty_borders_in_psql

1)

The unicode-double5 style looks like:

x=# select * from t;
┌───┬───┬───┐
│ a │ b │ t │
╞═══╪═══╪═══╡
│ 1 │ 1 │ a │
├───┼───┼───┤
│ 2 │ 2 │ b │
├───┼───┼───┤
│ 3 │ 3 │ c │
└───┴───┴───┘
(3 rows)

(There are horizontal lines between rows)

2) There is no unicode-double6 in psql, however it exists on the website.

regards,
Szymon


[HACKERS] Clang support

2013-11-19 Thread Szymon Guz
Hi,
is clang supported for compiling Postgres? I found some websites with
information that some people compiled Postgres succesfully, but I got
plenty of errors even with running ./configure. So I'm wondering if it's my
fault, however gcc works properly.

thanks,
Szymon


Re: [HACKERS] Clang support

2013-11-19 Thread Szymon Guz
On 19 November 2013 22:54, Kevin Grittner kgri...@ymail.com wrote:

 Szymon Guz mabew...@gmail.com wrote:

  is clang supported for compiling Postgres? I found some websites
  with information that some people compiled Postgres succesfully,
  but I got plenty of errors even with running ./configure. So I'm
  wondering if it's my fault, however gcc works properly.

 I am able to build with this version of clang:

 Ubuntu clang version 3.4-1~exp1 (trunk) (based on LLVM 3.4)
 Target: x86_64-pc-linux-gnu
 Thread model: posix

 All I do is `export CC=clang` before running ./configure and make.

 I was getting three benign warnings which didn't show up for gcc,
 and recently committed changes to quiet those.



Hi Kevin,
thanks for the answer.

I still get about twenty errors like:

checking zlib.h usability... no
checking zlib.h presence... yes
configure: WARNING: zlib.h: present but cannot be compiled
configure: WARNING: zlib.h: check for missing prerequisite headers?
configure: WARNING: zlib.h: see the Autoconf documentation
configure: WARNING: zlib.h: section Present But Cannot Be Compiled
configure: WARNING: zlib.h: proceeding with the preprocessor's result
configure: WARNING: zlib.h: in the future, the compiler will take precedence
configure: WARNING: ##  ##
configure: WARNING: ## Report this to pgsql-b...@postgresql.org ##
configure: WARNING: ##  ##

But it seems that I'm using older clang:
Debian clang version 3.2-7ubuntu1 (tags/RELEASE_32/final) (based on LLVM
3.2)
Target: x86_64-pc-linux-gnu
Thread model: posix

So maybe that's the problem, I will update clang and try once again.

thanks,
Szymon


Re: [HACKERS] Clang support

2013-11-19 Thread Szymon Guz
On 19 November 2013 23:02, Szymon Guz mabew...@gmail.com wrote:

 On 19 November 2013 22:54, Kevin Grittner kgri...@ymail.com wrote:

 Szymon Guz mabew...@gmail.com wrote:

  is clang supported for compiling Postgres? I found some websites
  with information that some people compiled Postgres succesfully,
  but I got plenty of errors even with running ./configure. So I'm
  wondering if it's my fault, however gcc works properly.

 I am able to build with this version of clang:

 Ubuntu clang version 3.4-1~exp1 (trunk) (based on LLVM 3.4)
 Target: x86_64-pc-linux-gnu
 Thread model: posix

 All I do is `export CC=clang` before running ./configure and make.

 I was getting three benign warnings which didn't show up for gcc,
 and recently committed changes to quiet those.



 Hi Kevin,
 thanks for the answer.

 I still get about twenty errors like:

 checking zlib.h usability... no
 checking zlib.h presence... yes
 configure: WARNING: zlib.h: present but cannot be compiled
 configure: WARNING: zlib.h: check for missing prerequisite headers?
 configure: WARNING: zlib.h: see the Autoconf documentation
 configure: WARNING: zlib.h: section Present But Cannot Be Compiled
 configure: WARNING: zlib.h: proceeding with the preprocessor's result
 configure: WARNING: zlib.h: in the future, the compiler will take
 precedence
 configure: WARNING: ##  ##
 configure: WARNING: ## Report this to pgsql-b...@postgresql.org ##
 configure: WARNING: ##  ##

 But it seems that I'm using older clang:
 Debian clang version 3.2-7ubuntu1 (tags/RELEASE_32/final) (based on LLVM
 3.2)
 Target: x86_64-pc-linux-gnu
 Thread model: posix

 So maybe that's the problem, I will update clang and try once again.


Yep, that's the problem. After updating to clang 3.4, there were no errors
in configuring and compilation runs properly so far.

thanks,
Szymon


Re: [HACKERS] How to create read-only view on 9.3

2013-08-13 Thread Szymon Guz
On 13 August 2013 11:43, Tomonari Katsumata 
katsumata.tomon...@po.ntts.co.jp wrote:

 Hi,

 Could anyone tell me how to create read-only view on
 PostgreSQL 9.3 ?

 I've been testing updatable views and noticed that
 all simple views are updatable.

 When I use pg_dump for upgrading from PostgreSQL 9.2
 to PostgreSQL 9.3 and if the databse has views,
 all views are updatable on the restored database.

 I want to make these views read-only like PostgreSQL9.2.
 How can I do this? Should I make access control on users ?
 (Sorry, I couldn't find any explanations on document.)

 regards,
 
 NTT Software Corporation
 Tomonari Katsumata



 Could you show an example?

Szymon


Re: [HACKERS] question about HTTP API

2013-08-12 Thread Szymon Guz
On 12 August 2013 18:37, Peter Eisentraut pete...@gmx.net wrote:

 On 8/8/13 3:44 PM, Josh Berkus wrote:
  Other than that, no.  I was thinking of creating a general tool as a
  custom background worker, which would take stored procedure calls and
  pass them through to PostgreSQL, returning results as JSON.  Mainly
  because I need it for a project.  However, this wouldn't accept any
 query.

 You can write such a thing in 20 lines of code as an external service.
 What's the value in having it has a background worker?  (Note also the
 term *background* worker.)  It just seems harder to manage and scale
 that way.


When I think about that, it seems to me like the only value of that would
be a nice sql command for starting a service. On the other hand I could
implement that in python/perl/C and start external server from the same sql
query. When I started this thread I was thinking about writing some super
simple app, in something like python/perl, and run it externally. I really
don't like idea of having that in core, as it will be another thing to
support, test etc. and another source of security/efficiency bugs. What we
really need is something like phpPgAdmin with JSON/XML/Something api.

And one more thing: I would never let my db users to start such a service
on their own.

Szymon


[HACKERS] question about HTTP API

2013-08-08 Thread Szymon Guz
Do we have any attempts of implementation the HTTP server described at
http://wiki.postgresql.org/wiki/HTTP_API?

It seems like there are design ideas only. Are there any ideas about
implementation like using some existing http servers or writing everything
from scratch?

regards
Szymon


[HACKERS] potential bug in error message in with clause

2013-07-29 Thread Szymon Guz
Hi,
today on IRC there was a strange problem shown. The small working example
looks like this:

x=# with x as (insert into a(t) values('1') returning *) select * from x;
 t
---
 1
(1 row)

x=# with x (insert into a(t) values('1') returning *) select * from x;
ERROR:  syntax error at or near into
LINE 1: with x (insert into a(t) values('1') returning *) select * f...
   ^

The initial code was run on 9.2; I've checked that on 9.4devel.

The error message is really not useful, as there is missing as after
with x. There is no problem with into.

regards
Szymon


Re: [HACKERS] ToDo: possible more rights to database owners

2013-07-29 Thread Szymon Guz
On 29 July 2013 11:25, Pavel Stehule pavel.steh...@gmail.com wrote:

 Hello

 In 9.3 super user can cancel all queries or user can cancel own sessions.

 Is possible enhance this possibility to database owners? So owner can
 cancel or can terminate sessions related to owned databases?


But this means that a db owner could cancel superuser's super important
database query. Maybe let's make a default that the owner can cancel all
queries except for superuser's ones. And additionaly a special right that
superuser can grant it to the db owner, so the owner can cancel even
superuser's queries?

szymon


Re: [HACKERS] ToDo: possible more rights to database owners

2013-07-29 Thread Szymon Guz
On 29 July 2013 13:20, Pavel Stehule pavel.steh...@gmail.com wrote:

 2013/7/29 Szymon Guz mabew...@gmail.com:
  On 29 July 2013 11:25, Pavel Stehule pavel.steh...@gmail.com wrote:
 
  Hello
 
  In 9.3 super user can cancel all queries or user can cancel own
 sessions.
 
  Is possible enhance this possibility to database owners? So owner can
  cancel or can terminate sessions related to owned databases?
 
 
  But this means that a db owner could cancel superuser's super important
  database query. Maybe let's make a default that the owner can cancel all
  queries except for superuser's ones. And additionaly a special right that
  superuser can grant it to the db owner, so the owner can cancel even
  superuser's queries?

 I am thinking so owner cannot cancel super user is enough. It allows
 simply cancelling and terminating connects where we have more
 application roles without superuser rights.


I agree.


Re: [HACKERS] [COMMITTERS] pgsql: PL/Python: Convert numeric to Decimal

2013-07-07 Thread Szymon Guz
On 7 July 2013 21:35, Peter Eisentraut pete...@gmx.net wrote:

 On Sun, 2013-07-07 at 17:21 +0200, Szymon Guz wrote:
  I think that these tests are much better, so they should go into
  trunk.
  As for Python 2.5 I think we could modify the code and makefile (with
  additional documentation info) so the decimal code wouldn't be
  compiled
  with python 2.5.

 I'd welcome updated tests, if you want to work on that.  But they would
 need to work uniformly for Python 2.4 through 3.3.



Well... I don't know what to do and which solution is better.

This patch works, but the tests are not working on some old machines.

This patch works, but changes the plpython functions, so I assume that it
will provide errors to some existing functions. I've noticed yesterday that
you cannot run code like `Decimal(10) - float(10)`. So if a function
accepts a numeric parameter 'x', which currently is converted to float,
then the code like `x - float(10)` currently works, and will not work after
this change.

Introducing decimal.Decimal also breaks python earlier than 2.4, as the
decimal module has been introduced in 2.4. We could use the old conversion
for versions before 2.4, and the new for 2.4 and newer. Do we want it to
work like this? Do we want to have different behaviour for different python
versions? I'm not sure if anyone still uses Python 2.3, but I've already
realised that the patch breaks all the functions for 2.3 which use numeric
argument.

I assume that the patch will be rolled back, if it the tests don't work on
some machines, right?

szymon


Re: [HACKERS] [PATCH] Fix conversion for Decimal arguments in plpython functions

2013-07-06 Thread Szymon Guz
On 28 June 2013 22:29, Claudio Freire klaussfre...@gmail.com wrote:

 On Fri, Jun 28, 2013 at 5:14 PM, Steve Singer st...@ssinger.info wrote:
  On 06/27/2013 05:04 AM, Szymon Guz wrote:
 
  On 27 June 2013 05:21, Steve Singer st...@ssinger.info
  mailto:st...@ssinger.info wrote:
 
  On 06/26/2013 04:47 PM, Szymon Guz wrote:
 
 
 
 
 
 
  Hi Steve,
  thanks for the changes.
 
  You're idea about common code for decimal and cdecimal is good, however
  not good enough. I like the idea of common code for decimal and
 cdecimal.
  But we need class name, not the value.
 
  I've changed the code from str(x) to x.__class__.__name__ so the
 function
  prints class name (which is Decimal for both packages), not the value.
 We
  need to have the class name check. The value is returned by the
 function and
  is a couple of lines lower in the file.
 
  patch is attached.
 
 
  I think the value is more important than the name, I want to the tests to
  make sure that the conversion is actually converting properly.  With your
  method of getting the class name without the module we can have both.
 
  The attached patch should print the value and the class name but not the
  module name.


 Why not forego checking of the type, and instead check the interface?

 plpy.info(x.as_tuple())

 Should do.

  d  = decimal.Decimal((0,(3,1,4),-2))
  d.as_tuple()
 DecimalTuple(sign=0, digits=(3, 1, 4), exponent=-2)
  d.as_tuple() == (0,(3,1,4),-2)
 True
  d = decimal.Decimal(3.14)
  d.as_tuple()
 DecimalTuple(sign=0, digits=(3, 1, 4), exponent=-2)
  d.as_tuple() == (0,(3,1,4),-2)
 True
 


Yea, however decimal and cdecimal have different outputs:

For decimal:

! INFO:  DecimalTuple(sign=1, digits=(1, 0, 0), exponent=0)

for cdecimal:

! INFO:  DecimalTuple(sign=1, digits=(1, 0, 0), exponent=0L)


Re: [HACKERS] [COMMITTERS] pgsql: PL/Python: Convert numeric to Decimal

2013-07-06 Thread Szymon Guz
On 6 July 2013 17:58, Claudio Freire klaussfre...@gmail.com wrote:

 Look at that:

   return x
   $$ LANGUAGE plpythonu;
   SELECT * FROM test_type_conversion_numeric(100);
 ! INFO:  (Decimal('100'), 'Decimal')
   CONTEXT:  PL/Python function test_type_conversion_numeric
test_type_conversion_numeric
   --
 --- 219,225 
   return x
   $$ LANGUAGE plpythonu;
   SELECT * FROM test_type_conversion_numeric(100);
 ! INFO:  (Decimal(100), 'Decimal')
   CONTEXT:  PL/Python function test_type_conversion_numeric
test_type_conversion_numeric
   --

  instead of '

 All the more reason to use as_tuple



 On Sat, Jul 6, 2013 at 9:16 AM, Andrew Dunstan and...@dunslane.net
 wrote:
 
  On 07/06/2013 01:52 AM, Claudio Freire wrote:
 
  On Sat, Jul 6, 2013 at 2:39 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 
  Peter Eisentraut pete...@gmx.net writes:
 
  PL/Python: Convert numeric to Decimal
 
  Assorted buildfarm members don't like this patch.
 
 
  Do you have failure details?
 
  This is probably an attempt to operate decimals vs floats.
 
  Ie: Decimal('3.0')  0 works, but Decimal('3.0')  1.3 doesn't
  (decimal is explicitly forbidden from operating on floats, some design
  decision that can only be disabled in 3.3).
 
 
 
 
  Instead of speculating, you can actually see for yourself. The dashboard
 is
  at http://www.pgbuildfarm.org/cgi-bin/show_status.pl Pick one of the
  machines failing at PLCheck-C and click its 'Details' link. Then scroll
 down
  a bit and you'll see what is failing.
 
  cheers
 
  andrew
 


Hi,
I've modifled the tests to check the numeric-decimal conversion some other
way. They check now conversion to float/int and to string, and also tuple
values.

I've checked that on decimal and cdecimal on python 2.7 and 3.3. The
outputs are the same regardles the Python and decimal versions.

thanks,
Szymon


fix_plpython_decimal_tests.patch
Description: Binary data

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


[HACKERS] plpython implementation

2013-06-30 Thread Szymon Guz
I'm reading through plperl and plpython implementations and I don't
understand the way they work.

Comments for plperl say that there are two interpreters (trusted and
untrusted) for each user session, and they are stored in a hash.

Plpython version looks quite different, there is no such global hash with
interpreters, there is just a pointer to an interpreter and one global
function _PG_init, which runs once (but per session, user, or what?).

I'm just wondering how a plpython implementation should look like. We need
another interpreter, but PG_init function is run once, should it then
create two interpreters on init, or should we let this function do nothing
and create a proper interpreter in the first call of plpython(u) function
for current session?

thanks,
Szymon


Re: [HACKERS] plpython implementation

2013-06-30 Thread Szymon Guz
On 30 June 2013 14:13, Andrew Dunstan and...@dunslane.net wrote:


 On 06/30/2013 07:49 AM, Szymon Guz wrote:

 I'm reading through plperl and plpython implementations and I don't
 understand the way they work.

 Comments for plperl say that there are two interpreters (trusted and
 untrusted) for each user session, and they are stored in a hash.

 Plpython version looks quite different, there is no such global hash with
 interpreters, there is just a pointer to an interpreter and one global
 function _PG_init, which runs once (but per session, user, or what?).

 I'm just wondering how a plpython implementation should look like. We
 need another interpreter, but PG_init function is run once, should it then
 create two interpreters on init, or should we let this function do nothing
 and create a proper interpreter in the first call of plpython(u) function
 for current session?




 python does not any any sort of reliable sandbox, so there is no plpython,
 only plpythonu - hence only one interpreter per backend is needed.


Is there any track of the discussion that there is no way to make the
sandbox? I managed to create some kind of sandbox, a simple modification
which totally disables importing modules, so I'm just wondering why it
cannot be done.

Szymon


Re: [HACKERS] plpython implementation

2013-06-30 Thread Szymon Guz
On 30 June 2013 14:31, Martijn van Oosterhout klep...@svana.org wrote:

 On Sun, Jun 30, 2013 at 02:18:07PM +0200, Szymon Guz wrote:
   python does not any any sort of reliable sandbox, so there is no
 plpython,
   only plpythonu - hence only one interpreter per backend is needed.
  
  Is there any track of the discussion that there is no way to make the
  sandbox? I managed to create some kind of sandbox, a simple modification
  which totally disables importing modules, so I'm just wondering why it
  cannot be done.

 http://wiki.python.org/moin/SandboxedPython

 This is the thread I was thinking of:
 http://mail.python.org/pipermail/python-dev/2009-February/086401.html

 If you read through it I think you will understand the difficulties.


Hi Martin,
thanks for links. I was thinking about something else. In fact we don't
need full sandbox, I think it would be enough to have safe python, if it
couldn't import any outside module. Wouldn't be enough?

It seems like the sandbox modules want to limit many external operations,
I'm thinking about not being able to import any module, even standard ones,
wouldn't be enough?

Szymon


Re: [HACKERS] plpython implementation

2013-06-30 Thread Szymon Guz
On 30 June 2013 14:45, Andres Freund and...@2ndquadrant.com wrote:

 On 2013-06-30 14:42:24 +0200, Szymon Guz wrote:
  On 30 June 2013 14:31, Martijn van Oosterhout klep...@svana.org wrote:
 
   On Sun, Jun 30, 2013 at 02:18:07PM +0200, Szymon Guz wrote:
 python does not any any sort of reliable sandbox, so there is no
   plpython,
 only plpythonu - hence only one interpreter per backend is needed.

Is there any track of the discussion that there is no way to make the
sandbox? I managed to create some kind of sandbox, a simple
 modification
which totally disables importing modules, so I'm just wondering why
 it
cannot be done.
  
   http://wiki.python.org/moin/SandboxedPython
  
   This is the thread I was thinking of:
   http://mail.python.org/pipermail/python-dev/2009-February/086401.html
  
   If you read through it I think you will understand the difficulties.
  
  thanks for links. I was thinking about something else. In fact we don't
  need full sandbox, I think it would be enough to have safe python, if it
  couldn't import any outside module. Wouldn't be enough?
 
  It seems like the sandbox modules want to limit many external operations,
  I'm thinking about not being able to import any module, even standard
 ones,
  wouldn't be enough?

 python
  open('/etc/passwd', 'r').readlines()


thanks :)


Re: [HACKERS] [PATCH] Fix conversion for Decimal arguments in plpython functions

2013-06-28 Thread Szymon Guz
On 28 June 2013 22:14, Steve Singer st...@ssinger.info wrote:


 I think the value is more important than the name, I want to the tests to
 make sure that the conversion is actually converting properly.  With your
 method of getting the class name without the module we can have both.

 The attached patch should print the value and the class name but not the
 module name.

 Steve


Hi Steve,
I agree, we can check both. This is quite a nice patch now, I've reviewed
it, all tests pass, works as expected. I think it is ready for committing.

thanks,
Szymon


Re: [HACKERS] [PATCH] Fix conversion for Decimal arguments in plpython functions

2013-06-27 Thread Szymon Guz
On 27 June 2013 05:21, Steve Singer st...@ssinger.info wrote:

 On 06/26/2013 04:47 PM, Szymon Guz wrote:





 Attached patch has all changes against trunk code.

 There is added a function for conversion from Postgres numeric to Python
 Decimal. The Decimal type is taken from cdecimal.Decimal, if it is
 available. It is an external library, quite fast, but may be not available.
 If it is not available, then decimal.Decimal will be used. It is in
 standard Python library, however it is rather slow.

 The initialization is done in the conversion function, the pointer to a
 proper Decimal constructor is stored as static variable inside the function
 and is lazy initialized.

 The documentation is updated.


 I've tested this version with python 2.7 with and without cdecimal and
 also with 3.3 that has the faster decimal performance. It seems fine.

 The v5 version of the patch makes only white-space changes to plpy_main.c
 you should excluded that from the patch if your making a new version (I
 have done this in the v6 version I'm attaching)



  Tests for python 2 and 3 have been added. They work only with standard
 decimal.Decimal, as the type is printed in the *.out files. I think there
 is nothing we can do with that now.



 I think we should make  test_type_conversion_numeric to do something that
 generates the same output in both cases.  ie
 py.info(str(x)).  I downside of having the test fail on installs with
 cdecimal installed is much greater than any benefit we get by ensuring that
 the type is really decimal.
 I've attached a v6 version of the patch that does this, do you agree with
 my thinking?


Hi Steve,
thanks for the changes.

You're idea about common code for decimal and cdecimal is good, however not
good enough. I like the idea of common code for decimal and cdecimal. But
we need class name, not the value.

I've changed the code from str(x) to x.__class__.__name__ so the function
prints class name (which is Decimal for both packages), not the value. We
need to have the class name check. The value is returned by the function
and is a couple of lines lower in the file.

patch is attached.

thanks,
Szymon


plpython_decimal_v7.patch
Description: Binary data

-- 
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] Fix conversion for Decimal arguments in plpython functions

2013-06-26 Thread Szymon Guz
On 26 June 2013 01:40, Steve Singer st...@ssinger.info wrote:

 On 06/25/2013 06:42 AM, Szymon Guz wrote:



 Hi,

 I've attached a new patch. I've fixed all the problems you've found,
 except for the efficiency problem, which has been described in previous
 email.

 thanks,
 Szymon


 This version of the patch addresses the issues I mentioned.  Thanks for
 looking into seeing if the performance issue is with our conversions to
 strings or inherit with the python decimal type.  I guess we (Postgresql)
 can't do much about it.   A runtime switch to use cdecimal if it is
 available is a good idea, but I agree with you that could be a different
 patch.

 One minor thing I noticed in this round,

  PLy_elog(ERROR, could not import module 'decimal');

 I think should have decimal in double-quotes.

 I think this patch is ready for a committer to look at it.

 Steve




Hi Steve,
thanks for the review.

I was thinking about speeding up the Decimal conversion using the module
you wrote about. What about trying to import it, if it fails, than trying
to load decimal.Decimal? There will be no warning in logs, just additional
information in documentation that it uses this module if it is available?

thanks,
Szymon


Re: [HACKERS] Add more regression tests for CREATE OPERATOR

2013-06-26 Thread Szymon Guz
OK, so I think this patch can be committed, I will change the status.

thanks,
Szymon

On 26 June 2013 09:26, Robins Tharakan thara...@gmail.com wrote:

 Hi Szymon,

 The commented out test that you're referring to, is an existing test (not
 that I added or commented). I was going to remove but interestingly its
 testing a part of code where (prima-facie) it should fail, but it passes
 (probably why it was disabled in the first place)
 !


 So technically I hope this regression patch I submitted could go through
 since this feedback isn't towards that patch, but in my part I am quite
 intrigued about this test (and how it passes) and probably I'd get back on
 this thread about this particular commented out test in question, as time
 permits.

 --
 Robins Tharakan


 On 25 June 2013 04:12, Robins Tharakan thara...@gmail.com wrote:

  Thanks a ton Szymon (for a reminder on this one).

 As a coincidental turn of events, I have had to travel half way across
 the world and am without my personal laptop (without a linux distro etc.)
 and just recovering from a jet-lag now.

 I'll try to install a VM on a make-shift laptop and get something going
 to respond as soon as is possible.

 Thanks
 --
 Robins Tharakan

 --
 Robins Tharakan


 On 17 June 2013 05:19, Szymon Guz mabew...@gmail.com wrote:

 On 23 May 2013 00:34, Robins Tharakan thara...@gmail.com wrote:

 Hi,

 Please find attached a patch to take code-coverage of CREATE OPERATOR
 (src/backend/commands/operatorcmds.c) from 56% to 91%.

 Any and all feedback is welcome.
 --
 Robins Tharakan


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


 Hi,
 there is one commented out test. I think it should be run, or deleted.
 There is no use of commented sql code which is not run.

 What do you think?

 regards,
 Szymon






Re: [HACKERS] [PATCH] Fix conversion for Decimal arguments in plpython functions

2013-06-26 Thread Szymon Guz
Thanks Steve, that's exactly what I wanted to send when you sent your
patches :)

I need to figure out why that patch v2 worked for me, I think I made mess
somewhere in my git repo and didn't create the patch properly. Sorry for
that.

Patch is attached, I've also added information about cdecimal to plpython
documentation.

I'm just wondering how to make integration tests to check when cdecimal is
installed and when it is not.

thanks,
Szymon


On 26 June 2013 10:12, Ronan Dunklau rdunk...@gmail.com wrote:

 The v2 patch does not work for me: regression tests for plpython fail on
 the plpython_types test: every numeric is converted to None.

 It seems the global decimal ctor is not initialized.

 Please find two patches, to be applied on top of the v2 patch: one
 initializes the decimal ctor, the other uses cdecimal when possible.

 Using the performance test from steve, on my machine:

 - with cdecimal installed: ~84ms
 - without cdecimal installed (standard decimal module): ~511ms


 2013/6/26 Szymon Guz mabew...@gmail.com

 On 26 June 2013 01:40, Steve Singer st...@ssinger.info wrote:

 On 06/25/2013 06:42 AM, Szymon Guz wrote:



 Hi,

 I've attached a new patch. I've fixed all the problems you've found,
 except for the efficiency problem, which has been described in previous
 email.

 thanks,
 Szymon


 This version of the patch addresses the issues I mentioned.  Thanks for
 looking into seeing if the performance issue is with our conversions to
 strings or inherit with the python decimal type.  I guess we (Postgresql)
 can't do much about it.   A runtime switch to use cdecimal if it is
 available is a good idea, but I agree with you that could be a different
 patch.

 One minor thing I noticed in this round,

  PLy_elog(ERROR, could not import module 'decimal');

 I think should have decimal in double-quotes.

 I think this patch is ready for a committer to look at it.

 Steve




 Hi Steve,
 thanks for the review.

 I was thinking about speeding up the Decimal conversion using the module
 you wrote about. What about trying to import it, if it fails, than trying
 to load decimal.Decimal? There will be no warning in logs, just additional
 information in documentation that it uses this module if it is available?

 thanks,
 Szymon





plpython_decimal_v3.patch
Description: Binary data

-- 
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] Fix conversion for Decimal arguments in plpython functions

2013-06-26 Thread Szymon Guz
You had a great idea, the time with cdecimal is really great, the
difference on my machine is 64 ms vs 430 ms.

Szymon


Re: [HACKERS] [PATCH] Fix conversion for Decimal arguments in plpython functions

2013-06-26 Thread Szymon Guz
On 26 June 2013 12:04, Ronan Dunklau rdunk...@gmail.com wrote:

 It seems like you confused me with steve :)


Hi Ronan,
Oh, yes. I'm sorry for that :)


 The patch applies cleanly, and the regression tests pass on python2 when
 cdecimal is not installed. When it is, the type info returned for the
 converted numeric value is cdecimal.Decimal instead of decimal.Decimal.

 The regression tests expected output have not been modified for python3,
 and as such they fail on the type conversions.

 I am a bit confused with the use of PyModule_GetDict: shouldn't
 PyObj_GetAttrString be used directly instead ? Moreover, the reference
 count in the current implementation might be off: the reference count for
 the decimal module is never decreased, while the reference count to the
 module dict is, when the docs say it returns a borrowed reference.

 Please find a patch that fixes both issues.


Thanks for the patch. I assume you generated that from clean trunk, and it
includes all the changes (mine and yours) right?

I've checked the patch, everything looks great.
I've attached it to this email with changed name, just for consistent
naming in commitfest app.

thanks,
Szymon


plpython_decimal_v4.patch
Description: Binary data

-- 
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 more regression tests for CREATE OPERATOR

2013-06-26 Thread Szymon Guz
On 26 June 2013 20:55, Josh Berkus j...@agliodbs.com wrote:

 On 06/26/2013 12:29 AM, Szymon Guz wrote:
  OK, so I think this patch can be committed, I will change the status.

 Can we have a full review before you mark it ready for committer?  How
 did you test it?  What kinds of review have you done?

 The committer can't know whether it's ready or not if he doesn't have a
 full report from you.

 Thanks!


Hi Josh,
I will add more detailed descriptions to all patches I set as read for
committer.

Szymon


Re: [HACKERS] Add more regression tests for CREATE OPERATOR

2013-06-26 Thread Szymon Guz
On 26 June 2013 20:57, Szymon Guz mabew...@gmail.com wrote:

 On 26 June 2013 20:55, Josh Berkus j...@agliodbs.com wrote:

 On 06/26/2013 12:29 AM, Szymon Guz wrote:
  OK, so I think this patch can be committed, I will change the status.

 Can we have a full review before you mark it ready for committer?  How
 did you test it?  What kinds of review have you done?

 The committer can't know whether it's ready or not if he doesn't have a
 full report from you.

 Thanks!




Hi Josh,
so I've got a couple of questions.

Is it enough to provide the description in the commitfest app, or is that
better to send an email and provide link in commitfest?

This is a patch only with regression tests, is that enough to write
something like: This patch applies cleanly on trunk code. All tests pass,
the test coverage increses as provided.? Or do you expect some more info?

thanks,
Szymon


Re: [HACKERS] Add more regression tests for CREATE OPERATOR

2013-06-26 Thread Szymon Guz
On 26 June 2013 21:10, Josh Berkus j...@agliodbs.com wrote:


  Is it enough to provide the description in the commitfest app, or is that
  better to send an email and provide link in commitfest?

 Better to do it here, on the list.

  This is a patch only with regression tests, is that enough to write
  something like: This patch applies cleanly on trunk code. All tests
 pass,
  the test coverage increses as provided.? Or do you expect some more
 info?

 Yes, mainly:

 a) does it test what it purports to test?

 b) do the tests pass on your machine?


Done, could you confirm that it is OK now?
I've also checked all the patches on the newest trunk.

thanks,
Szymon


Re: [HACKERS] [PATCH] Fix conversion for Decimal arguments in plpython functions

2013-06-26 Thread Szymon Guz
On 26 June 2013 21:59, Peter Eisentraut pete...@gmx.net wrote:

 On 6/26/13 7:03 AM, Szymon Guz wrote:
  I've checked the patch, everything looks great.
  I've attached it to this email with changed name, just for consistent
  naming in commitfest app.

 Could the setup of the decimal.Decimal constructor be moved into
 PLyDecimal_FromNumeric() and kept in a static pointer?  I'd rather not
 clutter up the main initialization routine.


OK, I will.


Re: [HACKERS] [PATCH] Fix conversion for Decimal arguments in plpython functions

2013-06-26 Thread Szymon Guz
On 26 June 2013 22:08, Szymon Guz mabew...@gmail.com wrote:

 On 26 June 2013 21:59, Peter Eisentraut pete...@gmx.net wrote:

 On 6/26/13 7:03 AM, Szymon Guz wrote:
  I've checked the patch, everything looks great.
  I've attached it to this email with changed name, just for consistent
  naming in commitfest app.

 Could the setup of the decimal.Decimal constructor be moved into
 PLyDecimal_FromNumeric() and kept in a static pointer?  I'd rather not
 clutter up the main initialization routine.



Attached patch has all changes against trunk code.

There is added a function for conversion from Postgres numeric to Python
Decimal. The Decimal type is taken from cdecimal.Decimal, if it is
available. It is an external library, quite fast, but may be not available.
If it is not available, then decimal.Decimal will be used. It is in
standard Python library, however it is rather slow.

The initialization is done in the conversion function, the pointer to a
proper Decimal constructor is stored as static variable inside the function
and is lazy initialized.

The documentation is updated.

Tests for python 2 and 3 have been added. They work only with standard
decimal.Decimal, as the type is printed in the *.out files. I think there
is nothing we can do with that now.


regards,
Szymon


plpython_decimal_v5.patch
Description: Binary data

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


[HACKERS] converting datum to numeric

2013-06-25 Thread Szymon Guz
Hi,
I've got a couple of questions.

I was using numeric_out like this:

DatumGetCString(DirectFunctionCall1(numeric_out, d));

Why do I have to use DirectFunctionCall1 instead of calling numeric_out?


I was suggested to use numeric_send instead of numeric_out, however when
changing the function names in the above example, the whole expression
returns 8. Always 8. I check with:

char *x = DatumGetCString(DirectFunctionCall1(numeric_send, d));
PLy_elog(NOTICE, x).


And my main question: is there any documentation about those internal
functions, which use and when etc?

thanks
Szymon


Re: [HACKERS] converting datum to numeric

2013-06-25 Thread Szymon Guz
On 25 June 2013 08:51, Pavel Stehule pavel.steh...@gmail.com wrote:

 Hello

 2013/6/25 Szymon Guz mabew...@gmail.com:
  Hi,
  I've got a couple of questions.
 
  I was using numeric_out like this:
 
  DatumGetCString(DirectFunctionCall1(numeric_out, d));
 
  Why do I have to use DirectFunctionCall1 instead of calling numeric_out?

 numeric_out functions doesn't use C calling convention - it use own
 convention for support NULL values and some other informations.
 DirectFunctionCall1 is simple function that transform C like call to
 PostgreSQL call. You can do it directly, but you have to prepare
 necessary structures.

 
 
  I was suggested to use numeric_send instead of numeric_out, however when
  changing the function names in the above example, the whole expression
  returns 8. Always 8. I check with:
 
  char *x = DatumGetCString(DirectFunctionCall1(numeric_send, d));
  PLy_elog(NOTICE, x).
 

 send functions are used for binary protocol - so it is nonsense.



Hi,
thanks for the information. So I will leave speeding it up for this moment.

thanks,
Szymon


Re: [HACKERS] [PATCH] Fix conversion for Decimal arguments in plpython functions

2013-06-25 Thread Szymon Guz
On 25 June 2013 05:16, Steve Singer st...@ssinger.info wrote:


 One concern I have is that this patch makes pl/python functions involving
 numerics more than 3 times as slow as before.


 create temp table b(a numeric);
 insert into b select generate_series(1,1);

 create or replace function x(a numeric,b numeric) returns numeric as $$
 if a==None:
   return b
 return a+b
 $$ language plpythonu;
 create aggregate sm(basetype=numeric, sfunc=x,stype=numeric);


 test=# select sm(a) from b;
 sm
 --
  50005000
 (1 row)

 Time: 565.650 ms

 versus before the patch this was taking in the range of 80ms.

 Would it be faster to call numeric_send instead of numeric_out and then
 convert the sequence of Int16's to a tuple of digits that can be passed
 into the Decimal constructor? I think this is worth trying and testing,


Hi,
thanks for all the remarks.

I think I cannot do anything about speeding up the code. What I've found so
far is:

I cannot use simple fields from NumericVar in my code, so to not waste time
on something not sensible, I've tried to found out if using the tuple
constructor for decimal.Decimal will be faster. I've changed the function
to something like this:

static PyObject *
PLyDecimal_FromNumeric(PLyDatumToOb *arg, Datum d)
{
PyObject *digits = PyTuple_New(4);
PyTuple_SetItem(digits, 0, PyInt_FromLong(1));
PyTuple_SetItem(digits, 1, PyInt_FromLong(4));
PyTuple_SetItem(digits, 2, PyInt_FromLong(1));
PyTuple_SetItem(digits, 3, PyInt_FromLong(4));

PyObject *tuple = PyTuple_New(3);
PyTuple_SetItem(tuple, 0, PyInt_FromLong(1));
PyTuple_SetItem(tuple, 1, digits);
PyTuple_SetItem(tuple, 2, PyInt_FromLong(-3));

value = PyObject_CallFunctionObjArgs(PLy_decimal_ctor_global,
tuple, NULL);

return value;
}

Yes, it returns the same value regardless the params. The idea is to call
Python code like:

Decimal((0, (1,  4, 1, 4), -3))

which is simply:

Decimal('1.414')

Unfortunately this is not faster. It is as slow as it was with string
constructor.

I've checked the speed of decimal.Decimal using pure python. For this I
used a simple function, similar to yours:


def x(a, b):
if a is None:
return b
return a + b

I've run the tests using simple ints:


def test():
a = 0
for i in xrange(0, 1):
a += x(a, i)


for a in xrange(1, 100):
test()


And later I've run the same function, but with converting the arguments to
Decimals:

from decimal import Decimal


def x(a, b):
if a is None:
return b
return a + b


def test():
a = 0
for i in xrange(0, 1):
a += x(Decimal(a), Decimal(i))


for a in xrange(1, 100):
test()

It was run 100 times for decreasing the impact of test initialization.

The results for both files are:
int:  0.697s
decimal: 38.859s

What gives average time for one function call of:
int: 69ms
decimal: 380ms


For me the problem is with slow code at Python's side, the Decimal
constructors are pretty slow, and there is nothing I can do with that at
the Postgres' side.


I will send patch with fixes later.


thanks,
Szymon


Re: [HACKERS] [PATCH] Fix conversion for Decimal arguments in plpython functions

2013-06-25 Thread Szymon Guz
On 25 June 2013 05:16, Steve Singer st...@ssinger.info wrote:

 On 05/28/2013 04:41 PM, Szymon Guz wrote:

 Hi,
 I've got a patch.

 This is for a plpython enhancement.

 There is an item at the TODO list http://wiki.postgresql.org/**
 wiki/Todo#Server-Side_**Languageshttp://wiki.postgresql.org/wiki/Todo#Server-Side_Languages
 Fix loss of information during conversion of numeric type to Python
 float

 This patch uses a decimal.Decimal type from Python standard library for
 the plpthon function numeric argument instead of float.

 Patch contains changes in code, documentation and tests.

 Most probably there is something wrong, as this is my first Postgres
 patch :)


 Thanks for contributing.

 This patch applies cleanly against master and compiles with warnings

 plpy_main.c: In function ‘PLy_init_interp’:
 plpy_main.c:157:2: warning: ISO C90 forbids mixed declarations and code
 [-Wdeclaration-after-**statement]
 plpy_main.c:161:2: warning: ISO C90 forbids mixed declarations and code
 [-Wdeclaration-after-**statement]

 You can avoid this by moving the declaration of decimal and decimal_dict
 to be at the top of the function where mainmod is declared.

 Also in this function you've introduced places where it returns with an
 error (the PLy_elog(ERROR...) calls before decrementing the reference to
 mainmod. I think you can decrement the mainmod reference after the call to
 SetItemString  before your changes that import the Decimal module.


 The patch works as expected, I am able to write python functions that take
 numerics as arguments and work with them.  I can adjust the decimal context
 precision inside of  my function.

 One concern I have is that this patch makes pl/python functions involving
 numerics more than 3 times as slow as before.


 create temp table b(a numeric);
 insert into b select generate_series(1,1);

 create or replace function x(a numeric,b numeric) returns numeric as $$
 if a==None:
   return b
 return a+b
 $$ language plpythonu;
 create aggregate sm(basetype=numeric, sfunc=x,stype=numeric);


 test=# select sm(a) from b;
 sm
 --
  50005000
 (1 row)

 Time: 565.650 ms

 versus before the patch this was taking in the range of 80ms.

 Would it be faster to call numeric_send instead of numeric_out and then
 convert the sequence of Int16's to a tuple of digits that can be passed
 into the Decimal constructor? I think this is worth trying and testing,


 Documentation
 =
 Your patched version of the docs say

   PostgreSQL typereal/type, typedouble/type, and
 typenumeric/type are converted to
Python typeDecimal/type. This type is imported
 fromliteraldecimal.Decimal/**literal.


 I don't think this is correct, as far as I can tell your not changing the
 behaviour for postgresql real and double types, they continue to use
 floating point.



 listitem
 para
PostgreSQL typereal/type and typedouble/typeare converted to
Python typefloat/type.
 /para
 /listitem

 listitem
 para
PostgreSQL typenumeric/type is converted to
Python typeDecimal/type. This type is imported from
 literaldecimal.Decimal/**literal.
 /para
 /listitem


Hi,
I've attached a new patch. I've fixed all the problems you've found, except
for the efficiency problem, which has been described in previous email.

thanks,
Szymon


plpython_decimal_v2.patch
Description: Binary data

-- 
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] Fix conversion for Decimal arguments in plpython functions

2013-06-25 Thread Szymon Guz
Well, I really don't like the idea of such a dependency.

However it could be added as configuration option, so you could compile
postgres with e.g. --with-cdecimal, and then it would be user dependent.
Maybe it is a good idea for another patch.

On 25 June 2013 14:23, Ronan Dunklau rdunk...@gmail.com wrote:

 Concerning the efficiency problem, it should be noted that the latest 3.3
 release of cpython introduces an accelerator for decimal data types, as a
 C-module.  This module was previously available from the Python package
 index at: https://pypi.python.org/pypi/cdecimal/2.2

 It may be overkill to try to include such a dependency, but the
 performance overhead from using decimal is really mitigated by this
 implementation.


 2013/6/25 Szymon Guz mabew...@gmail.com

 On 25 June 2013 05:16, Steve Singer st...@ssinger.info wrote:

 On 05/28/2013 04:41 PM, Szymon Guz wrote:

 Hi,
 I've got a patch.

 This is for a plpython enhancement.

 There is an item at the TODO list http://wiki.postgresql.org/**
 wiki/Todo#Server-Side_**Languageshttp://wiki.postgresql.org/wiki/Todo#Server-Side_Languages
 Fix loss of information during conversion of numeric type to Python
 float

 This patch uses a decimal.Decimal type from Python standard library for
 the plpthon function numeric argument instead of float.

 Patch contains changes in code, documentation and tests.

 Most probably there is something wrong, as this is my first Postgres
 patch :)


 Thanks for contributing.

 This patch applies cleanly against master and compiles with warnings

 plpy_main.c: In function ‘PLy_init_interp’:
 plpy_main.c:157:2: warning: ISO C90 forbids mixed declarations and code
 [-Wdeclaration-after-**statement]
 plpy_main.c:161:2: warning: ISO C90 forbids mixed declarations and code
 [-Wdeclaration-after-**statement]

 You can avoid this by moving the declaration of decimal and decimal_dict
 to be at the top of the function where mainmod is declared.

 Also in this function you've introduced places where it returns with an
 error (the PLy_elog(ERROR...) calls before decrementing the reference to
 mainmod. I think you can decrement the mainmod reference after the call to
 SetItemString  before your changes that import the Decimal module.


 The patch works as expected, I am able to write python functions that
 take numerics as arguments and work with them.  I can adjust the decimal
 context precision inside of  my function.

 One concern I have is that this patch makes pl/python functions
 involving numerics more than 3 times as slow as before.


 create temp table b(a numeric);
 insert into b select generate_series(1,1);

 create or replace function x(a numeric,b numeric) returns numeric as $$
 if a==None:
   return b
 return a+b
 $$ language plpythonu;
 create aggregate sm(basetype=numeric, sfunc=x,stype=numeric);


 test=# select sm(a) from b;
 sm
 --
  50005000
 (1 row)

 Time: 565.650 ms

 versus before the patch this was taking in the range of 80ms.

 Would it be faster to call numeric_send instead of numeric_out and then
 convert the sequence of Int16's to a tuple of digits that can be passed
 into the Decimal constructor? I think this is worth trying and testing,


 Documentation
 =
 Your patched version of the docs say

   PostgreSQL typereal/type, typedouble/type, and
 typenumeric/type are converted to
Python typeDecimal/type. This type is imported
 fromliteraldecimal.Decimal/**literal.


 I don't think this is correct, as far as I can tell your not changing
 the behaviour for postgresql real and double types, they continue to use
 floating point.



 listitem
 para
PostgreSQL typereal/type and typedouble/typeare converted
 to
Python typefloat/type.
 /para
 /listitem

 listitem
 para
PostgreSQL typenumeric/type is converted to
Python typeDecimal/type. This type is imported from
 literaldecimal.Decimal/**literal.
 /para
 /listitem


 Hi,
 I've attached a new patch. I've fixed all the problems you've found,
 except for the efficiency problem, which has been described in previous
 email.

 thanks,
 Szymon


 --
 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] [9.4 CF 1] The Commitfest Slacker List

2013-06-24 Thread Szymon Guz
I'm just wondering about newbies...

I've created my first patch, so I'm one of them, I think.

I've reviewed some patches, but only some easier ones, like pure regression
tests. Unfortunately my knowledge is not enough to review patches making
very deep internal changes, or some efficiency tweaks. I'm not sure if
those patches should be reviewed by newbies like me, as I just don't know
what is good and what is bad, even if a patch looks OK for me. What's the
use of my review, if I don't understand the internals enough, I can apply
the patch, run tests, look inside and I'm sure I won't find any problems?

Maybe this is the reason why there are not so many reviewers?

I'm not sure if such a strict policy will bring anything good. If newbies
won't be able to review patches, they won't be committing simple patches,
as they won't be able to review others.

If this policy will be so strict, I will spend huge amount of time to
understand the whole Postgres code before sending my next patch, as most
probably I will have problems with making the reviews.


Szymon


Re: [HACKERS] is it bug? - printing boolean domains in sql/xml function

2013-06-24 Thread Szymon Guz
On 14 March 2013 03:45, Peter Eisentraut pete...@gmx.net wrote:

 On Mon, 2013-03-04 at 08:35 +0100, Pavel Stehule wrote:
  in this use case I am think so some regression test is important - It
  should not be mine, but missing more explicit regression test is
  reason, why this bug was not detected some years.

 I've added the tests.



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



Hi,
how should I apply the patch from fix-xmlmap.patch? I've run out of ideas.

When I run it normally, I get:

$ patch --verbose --dry-run -p1  fix-xmlmap.patch
Hmm...(Fascinating -- this is really a new-style context diff but without
the telltale extra asterisks on the *** line that usually indicate
the new style...)
  Looks like a context diff to me...
The text leading up to this was:
--
|*** a/src/backend/utils/adt/xml.c
|--- b/src/backend/utils/adt/xml.c
--
Patching file src/backend/utils/adt/xml.c using Plan A...
(Fascinating -- this is really a new-style context diff but without
the telltale extra asterisks on the *** line that usually indicate
the new style...)
Hunk #1 succeeded at 2002 with fuzz 2 (offset 1 line).
Hmm...(Fascinating -- this is really a new-style context diff but without
the telltale extra asterisks on the *** line that usually indicate
the new style...)
  The next patch looks like a context diff to me...
The text leading up to this was:
--
|*** a/src/test/regress/expected/xmlmap.out
|--- b/src/test/regress/expected/xmlmap.out
--
Patching file src/test/regress/expected/xmlmap.out using Plan A...
(Fascinating -- this is really a new-style context diff but without
the telltale extra asterisks on the *** line that usually indicate
the new style...)
Hunk #1 succeeded at 1201 (offset 27 lines).
Hmm...(Fascinating -- this is really a new-style context diff but without
the telltale extra asterisks on the *** line that usually indicate
the new style...)
  The next patch looks like a context diff to me...
The text leading up to this was:
--
|*** a/src/test/regress/sql/xmlmap.sql
|--- b/src/test/regress/sql/xmlmap.sql
--
Patching file src/test/regress/sql/xmlmap.sql using Plan A...
(Fascinating -- this is really a new-style context diff but without
the telltale extra asterisks on the *** line that usually indicate
the new style...)
Hunk #1 FAILED at 39.
1 out of 1 hunk FAILED -- saving rejects to file
src/test/regress/sql/xmlmap.sql.rej
done


thanks,
Szymon


Re: [HACKERS] Add regression tests for SET xxx

2013-06-18 Thread Szymon Guz
On 18 June 2013 02:33, Robins Tharakan thara...@gmail.com wrote:

 Thanks !

 PFA the updated patch. Also remove a trailing whitespace at the end of SQL
 script.

 --
 Robins Tharakan


 On 17 June 2013 17:29, Szymon Guz mabew...@gmail.com wrote:

 On 26 May 2013 19:56, Robins Tharakan thara...@gmail.com wrote:

 Hi,

 Please find attached a patch to take code-coverage of SET (SESSION /
 SEED / TRANSACTION / DATESTYLE / TIME ZONE) (
 src/backend/commands/variable.c) from 65% to 82%.

 Any and all feedback is welcome.
 --
 Robins Tharakan


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


 Hi,
 the patch applies cleanly on code from trunk, however there are failing
 tests, diff attached.

 regards
 Szymon



Hi,
I've checked the patch. Applies cleanly. Tests pass this time :)

Could you add me as a reviewer to commitfest website, set this patch a
reviewed and add this email to the patch history?
I cannot login to the commitfest app, there is some bug with that.

thanks,
Szymon Guz


Re: [HACKERS] Add regression tests for SET xxx

2013-06-18 Thread Szymon Guz
On 18 June 2013 13:10, Michael Paquier michael.paqu...@gmail.com wrote:

 On Tue, Jun 18, 2013 at 7:01 PM, Szymon Guz mabew...@gmail.com wrote:
  Could you add me as a reviewer to commitfest website, set this patch a
  reviewed and add this email to the patch history?
  I cannot login to the commitfest app, there is some bug with that.
 You should be able to do it yourself by creating a community account
 in postgresql.org.
 --
 Michael



Yea, I know. Unfortunately there is a bug and currently you cannot login to
commitfest using a new account, or old, if you changed password like I did.
I've got a bug confirmation from Magnus on pgsql-www list.

thanks,
Szymon


Re: [HACKERS] Add regression tests for SET xxx

2013-06-18 Thread Szymon Guz
On 18 June 2013 17:29, Kevin Grittner kgri...@ymail.com wrote:

 Szymon Guz mabew...@gmail.com wrote:

  I've checked the patch. Applies cleanly. Tests pass this time :)

  Could you add me as a reviewer to commitfest website, set this
  patch a reviewed and add this email to the patch history?
  I cannot login to the commitfest app, there is some bug with
  that.

 It sounded like you felt this was Ready for Committer, so I set it
 that way.  Let me know if you don't think it's to that point yet.


Hi Kevin,
yes, that's what I was thinking about.

Thanks,
Szymon


Re: [HACKERS] Add more regression tests for CREATE OPERATOR

2013-06-17 Thread Szymon Guz
On 23 May 2013 00:34, Robins Tharakan thara...@gmail.com wrote:

 Hi,

 Please find attached a patch to take code-coverage of CREATE OPERATOR
 (src/backend/commands/operatorcmds.c) from 56% to 91%.

 Any and all feedback is welcome.
 --
 Robins Tharakan


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


Hi,
there is one commented out test. I think it should be run, or deleted.
There is no use of commented sql code which is not run.

What do you think?

regards,
Szymon


Re: [HACKERS] Add regression tests for SET xxx

2013-06-17 Thread Szymon Guz
On 26 May 2013 19:56, Robins Tharakan thara...@gmail.com wrote:

 Hi,

 Please find attached a patch to take code-coverage of SET (SESSION / SEED
 / TRANSACTION / DATESTYLE / TIME ZONE) (src/backend/commands/variable.c)
 from 65% to 82%.

 Any and all feedback is welcome.
 --
 Robins Tharakan


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


Hi,
the patch applies cleanly on code from trunk, however there are failing
tests, diff attached.

regards
Szymon


regression.diffs
Description: Binary data

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


[HACKERS] converting numeric to string in postgres code

2013-05-28 Thread Szymon Guz
Hi,
while hacking on some Postgres code I've found a problem.

I need to convert numeric to string. I've got datum with numeric inside, so
I'm getting it like:

Numeric *numeric = DatumGetNumeric(d);

but later I need to have string (most probably: const char *). I've found a
couple of different ways for doing that, but I'm not aware of side effects.

Which function/macro should I use?

thanks,
Szymon


Re: [HACKERS] converting numeric to string in postgres code

2013-05-28 Thread Szymon Guz
On 28 May 2013 12:07, Pavel Stehule pavel.steh...@gmail.com wrote:

 Hello

 2013/5/28 Szymon Guz mabew...@gmail.com:
  Hi,
  while hacking on some Postgres code I've found a problem.
 
  I need to convert numeric to string. I've got datum with numeric inside,
 so
  I'm getting it like:
 
  Numeric *numeric = DatumGetNumeric(d);
 
  but later I need to have string (most probably: const char *). I've
 found a
  couple of different ways for doing that, but I'm not aware of side
 effects.
 
  Which function/macro should I use?
 

 There is a numeric_out function, you can use it or look on their source
 code

 result = DatumGetCString(DirectFunctionCall1(numeric_out, d));


Thanks.


[HACKERS] storing plpython global pointer

2013-05-28 Thread Szymon Guz
Hi,
I need to store a global pointer for plpython usage. This is a PyObject*
which can be initialized per session I think, as we have to deal with
Python 2 and Python 3. This pointer points to a Python constructor of
Python's Decimal type, taken from python stdlib.

I've got working code, however loading python module each time there is
Numeric argument in plpython function is not very efficient, so I'd like to
do it once and keep this somewhere. This has no side effects as this is a
pointer to a pure function.

Where should I keep such a pointer?

thanks,
Szymon


Re: [HACKERS] storing plpython global pointer

2013-05-28 Thread Szymon Guz
On 28 May 2013 14:15, Jan Urbański wulc...@wulczer.org wrote:

 On 28/05/13 14:04, Szymon Guz wrote:

 Hi,
 I need to store a global pointer for plpython usage. This is a PyObject*
 which can be initialized per session I think

 Where should I keep such a pointer?


 Hi,

 you probably could use a global variable, similar to PLy_interp_globals
 that's defined in plpy_main.c.

 Another method would be to expose the Decimal constructor in the plpy
 module. You could modify plpy_plpymodule.c to import decimal and expose the
 Decimal constructor as plpy.Decimal.

 Best,
 Jan


I think I'd rather go with the first solution, as this function should not
be accessible inside the plpython function. That's what I was thinking
about as well, but I wasn't sure.

thanks,
Szymon


[HACKERS] potential bug in JSON

2013-05-28 Thread Szymon Guz
I've found a potential bug. Why the - operator returns JSON instead of
TEXT? It doesn't make sens for me, and the documentation doesn't inform
about that.

postgres=# SELECT ('{id: 1}'::json - 'id')::int;
ERROR:  cannot cast type json to integer
LINE 1: SELECT ('{id: 1}'::json - 'id')::int;

postgres=# SELECT ('{id: 1}'::json - 'id')::text::int;
 int4
--
1
(1 row)


postgres=# SELECT version();
version

---
 PostgreSQL 9.3beta1 on x86_64-unknown-linux-gnu, compiled by gcc
(Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3, 64-bit
(1 row)


Re: [HACKERS] potential bug in JSON

2013-05-28 Thread Szymon Guz
On 28 May 2013 17:53, Josh Berkus j...@agliodbs.com wrote:

 On 05/28/2013 08:38 AM, Szymon Guz wrote:
  I've found a potential bug. Why the - operator returns JSON instead of
  TEXT? It doesn't make sens for me, and the documentation doesn't inform
  about that.

 Yes, it most certainly does:
 http://www.postgresql.org/docs/9.3/static/functions-json.html

 If you want to get text, use the - operator.



Yea, I noticed that. It was a little bit misleading for me that - is for
getting field and - is for getting field as text. Especially when
-::TEXT doesn't return the same value as -.
Maybe there should be added as JSON to those operators which don't return
text?

Szymon


[HACKERS] [PATCH] Fix conversion for Decimal arguments in plpython functions

2013-05-28 Thread Szymon Guz
Hi,
I've got a patch.

This is for a plpython enhancement.

There is an item at the TODO list
http://wiki.postgresql.org/wiki/Todo#Server-Side_Languages
Fix loss of information during conversion of numeric type to Python float

This patch uses a decimal.Decimal type from Python standard library for the
plpthon function numeric argument instead of float.

Patch contains changes in code, documentation and tests.

Most probably there is something wrong, as this is my first Postgres patch
:)

thanks,
Szymon


plpython_decimal.patch
Description: Binary data

-- 
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] adding import in pl/python function

2013-05-27 Thread Szymon Guz
On 28 May 2013 01:55, Peter Eisentraut pete...@gmx.net wrote:

 On Mon, 2013-05-27 at 20:43 -0300, Claudio Freire wrote:
  On Mon, May 27, 2013 at 8:13 PM, Peter Eisentraut pete...@gmx.net
 wrote:
   On Fri, 2013-05-24 at 16:46 -0300, Claudio Freire wrote:
   Well, it's easy.
  
   Instead of PLyFloat_FromNumeric[0], you can make a
   PLyDecimal_FromNumeric.
  
   Please send a patch.  This would be a welcome addition.
 
 
  I can write it blind as I have more than enough experience with
  CPython, but I don't use PLPython so I can't perform extensive
  testing.
  If someone's willing to do the testing, by all means.

 Yes please.


I'm working on that.

- Szymon


[HACKERS] adding import in pl/python function

2013-05-24 Thread Szymon Guz
Hi,
I'm wondering if it would be OK to change the procedure code before
execution. I'm thinking about adding magically an import at the beginning
of a function.

Currently numeric arguments passed to the procedure are converted into
floats. This is not good, as it causes loss of information.

The proposed solution in code comment is maybe use a string?.

I'm thinking about something else. We could convert it into Decimal (
http://docs.python.org/2/library/decimal.html) class in Python.
Unfortunately this class requires import like `from decimal import Decimal`
from a standard Python library.

I'm wondering if it would be a good idea to do it like this. It shouldn't
fail even with the trusted version of pl/python, as I'd rather see the
trusted version to allow importing packages from standard library.

regards,
Szymon


Re: [HACKERS] adding import in pl/python function

2013-05-24 Thread Szymon Guz
On 24 May 2013 21:14, Claudio Freire klaussfre...@gmail.com wrote:

 On Fri, May 24, 2013 at 4:10 PM, Szymon Guz mabew...@gmail.com wrote:
 
  I'm thinking about something else. We could convert it into Decimal
  (http://docs.python.org/2/library/decimal.html) class in Python.
  Unfortunately this class requires import like `from decimal import
 Decimal`
  from a standard Python library.
 
  I'm wondering if it would be a good idea to do it like this. It shouldn't
  fail even with the trusted version of pl/python, as I'd rather see the
  trusted version to allow importing packages from standard library.


 Why would passing a decimal require an import?

 The extension itself needs a reference to Decimal, to build them, but
 the procedure's context doesn't need to have it.


Hm... maybe you're right. I think I don't understand fully how the
procedures are executed, and I need to read more to get it.


thanks,
Szymon


Re: [HACKERS] adding import in pl/python function

2013-05-24 Thread Szymon Guz
On 24 May 2013 21:46, Claudio Freire klaussfre...@gmail.com wrote:

 On Fri, May 24, 2013 at 4:22 PM, Szymon Guz mabew...@gmail.com wrote:
  Hm... maybe you're right. I think I don't understand fully how the
  procedures are executed, and I need to read more to get it.


 Well, it's easy.

 Instead of PLyFloat_FromNumeric[0], you can make a
 PLyDecimal_FromNumeric. There, you'd do with the Python/C[1]:

 PyObject *decimal = PyImport_Import(decimal);
 PyObject *decimal_dict = PyModule_GetDict(decimal);
 PyObject *decimal_ctor = PyDict_GetItemString(decimal_dict, Decimal);

 And invoke it with a string rep of your Numeric:

 PyObject *value = PyObject_CallFunction(decimal_ctor, S, string_value);

 Add of course all kinds of error checking and reference count boiler
 plate, and you'd have a very dumb version of it.

 To make it more pro, you'd want to do all that stuff to get
 decimal_ctor only at initialization time. Especially since you don't
 want to fumble with the import lock right there in _FromNumeric.

 And to make it totally pro, you can even freeze Decimal (using
 pyfreeze) if you'd like. I would only do this in contexts where you
 don't have a stdlib of course. Not sure whether windows falls into
 that category. Linux doesn't.


 [0]
 http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/pl/plpython/plpy_typeio.c#l518
 [1] http://docs.python.org/2/c-api/import.html



Thanks, I will take a look at this, looks pretty easy. However testing on
Windows will be pretty funny :)

thanks,
Szymon


Re: [HACKERS] issues with dropped columns in plpgsql code again

2013-05-07 Thread Szymon Guz
On 7 May 2013 21:23, Pavel Stehule pavel.steh...@gmail.com wrote:

 sorry

 my test

 create table f1(a int, b int, c varchar, dropped_column numeric, d
 varchar);

 create or replace function f1_trg()
 returns trigger as $$
 declare _f1_var f1;
 begin raise notice 'run trigger';
   _f1_var := new;
   return _f1_var;
 end;
 $$ language plpgsql;

 create trigger xx before insert on f1 for row execute procedure f1_trg();

 insert into f1 values(1,1,'aaa',1.1,'aaa');
 alter table f1 drop column dropped_column ;

 insert into f1 values(1,1,'aaa','aaa');



Fails for me as well. I managed to run the last query either with
restarting session, or disabling the trigger.

Checked that on PostgreSQL 9.2.4 on x86_64-unknown-linux-gnu, compiled by
gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2, 64-bit

regards,
Szymon


Re: [HACKERS] Check if trigger was fired deferred

2013-02-27 Thread Szymon Guz
On 27 February 2013 10:20, Miroslav Šimulčík simulcik.m...@gmail.comwrote:

 Hi all,

 how can I check inside C trigger function if it was fired deferred?

 Thank you.

 Regards,
 Miro



I'd try tgdeferrable from Trigger struct:
http://www.postgresql.org/docs/9.2/static/trigger-interface.html

regards
Szymon


Re: [HACKERS] NOWAIT doesn't work

2012-10-31 Thread Szymon Guz
On 31 October 2012 14:52, Pavel Stehule pavel.steh...@gmail.com wrote:

 tested on 9.3

 Pavel

 2012/10/31 Pavel Stehule pavel.steh...@gmail.com:
  Hello
 
  it is expected behave?
 
  1.session
 
  postgres=# begin;
  BEGIN
  postgres=# lock oo IN ACCESS EXCLUSIVE MODE;
  LOCK TABLE
 
  2. session
 
  postgres=# select * from oo for update nowait;
 
  hangs forever 
 
  Regards
 
  Pavel Stehule



I've checked on 9.1, works exactly the same.

- Szymon


Re: [HACKERS] Should a materialized view be based on a view?

2011-11-18 Thread Szymon Guz
On 18 November 2011 23:26, Kevin Grittner kevin.gritt...@wicourts.govwrote:

 I still have a lot of reading to do before I propose anything
 concrete for development, but one thing that has already struck me
 as a common theme for MVs is that a lot of people seem to like the
 idea of first creating a normal view, and then materializing it.
 That seems pretty attractive to me, too.  How do people feel about
 that as a fundamental design decision: that a MV would always have
 a corresponding view (under a different name or in a different
 schema)?  Love it or hate it?

 -Kevin



Hi Kevin,
maybe a stupid question... but why? It looks like for creating a function I
should create another function earlier. For me the design should be simple.
If you want to create something below my MV, thats fine for me, if I don't
need to know that (just like when creating a serial column).


regards
Szymon


Re: [HACKERS] Storing original rows before update or delete

2011-11-04 Thread Szymon Guz
On 4 November 2011 10:20, Miroslav Šimulčík simulcik.m...@gmail.com wrote:

 Hi.

 I'm working on transactiontime temporal support for postgresql 9.0.4. Each
 original table with transactiontime support has associated history table,
 where original row is stored before each update or delete operation on it.
 Both original and history tables have internal timestamp columns for
 storing the period of validity of row versions. History tables are internal
 and I want to restrict any DML operation on it, so nobody can change
 history of operations made on original table. Problem is, that I don't know
 where to implement the mechanism for storing original rows to history
 tables. Rewrite rules are not suitable, because they are not working with
 inheritance and I can't use triggers, because inserts to history tables are
 restricted. Can you point me to place in postgresql backend where can i
 implement this and maybe give me some hints about how to do it correctly?

 Thank you.

 Best regards
 Miroslav Simulcik



Hi,
use triggers with security definer so the owner of the triggers and the
history table can insert into it, but normal user cannot - this user only
is able to change data in original table, and triggers will copy the data,
but will be executed using the first user credentials.
http://www.postgresql.org/docs/9.0/interactive/sql-createfunction.html

On the other hand: superuser always can delete data from a table, so you
cannot stop him from doing that.

regards
Szymon


[HACKERS] potential bug in trigger with boolean params

2011-05-11 Thread Szymon Guz
Hi,
I was trying to create a trigger with parameters. I've found a potential bug
when the param is boolean.

Here is code replicating the bug:

CREATE TABLE x(x TEXT);

CREATE OR REPLACE FUNCTION trigger_x() RETURNS TRIGGER AS $$
BEGIN
RETURN NEW;
END; $$ LANGUAGE PLPGSQL;

CREATE TRIGGER trig_x_text BEFORE INSERT ON x FOR EACH ROW EXECUTE PROCEDURE
trigger_x('text');
CREATE TRIGGER trig_x_int BEFORE INSERT ON x FOR EACH ROW EXECUTE PROCEDURE
trigger_x(10);
CREATE TRIGGER trig_x_float BEFORE INSERT ON x FOR EACH ROW EXECUTE
PROCEDURE trigger_x(42.0);
CREATE TRIGGER trig_x_bool BEFORE INSERT ON x FOR EACH ROW EXECUTE PROCEDURE
trigger_x(true);

ERROR:  syntax error at or near true
LINE 1: ... INSERT ON x FOR EACH ROW EXECUTE PROCEDURE trigger_x(true);


I've already checked that on:
'PostgreSQL 9.0.1, compiled by Visual C++ build 1500, 32-bit'
'PostgreSQL 9.0.4 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC)
4.1.2 20080704 (Red Hat 4.1.2-46), 64-bit'


If this is intended behavior, then the documentation doesn't say anything
about that.
The only information is that:

TG_ARGV[]

Data type array of text; the arguments from the CREATE TRIGGER statement.
but the below line throws the same error:

CREATE TRIGGER trig_x_bool BEFORE INSERT ON x FOR EACH ROW EXECUTE PROCEDURE
trigger_x( true::text );

while this obviously works:

SELECT true::text;

and this works as well:

CREATE TRIGGER trig_x_bool BEFORE INSERT ON x FOR EACH ROW EXECUTE PROCEDURE
trigger_x('true');
regards
Szymon


Re: [HACKERS] potential bug in trigger with boolean params

2011-05-11 Thread Szymon Guz
On 11 May 2011 10:56, t...@fuzzy.cz wrote:

  Hi,
  I was trying to create a trigger with parameters. I've found a potential
  bug
  when the param is boolean.
 
  Here is code replicating the bug:
 
  CREATE TABLE x(x TEXT);
 
  CREATE OR REPLACE FUNCTION trigger_x() RETURNS TRIGGER AS $$
  BEGIN
  RETURN NEW;
  END; $$ LANGUAGE PLPGSQL;
 
  CREATE TRIGGER trig_x_text BEFORE INSERT ON x FOR EACH ROW EXECUTE
  PROCEDURE
  trigger_x('text');
  CREATE TRIGGER trig_x_int BEFORE INSERT ON x FOR EACH ROW EXECUTE
  PROCEDURE
  trigger_x(10);
  CREATE TRIGGER trig_x_float BEFORE INSERT ON x FOR EACH ROW EXECUTE
  PROCEDURE trigger_x(42.0);
  CREATE TRIGGER trig_x_bool BEFORE INSERT ON x FOR EACH ROW EXECUTE
  PROCEDURE
  trigger_x(true);
 
  ERROR:  syntax error at or near true
  LINE 1: ... INSERT ON x FOR EACH ROW EXECUTE PROCEDURE trigger_x(true);

 The docs clearly state what the valid values are and the literal 'true' is
 not one of them (TRUE is). See this:

 http://www.postgresql.org/docs/9.0/interactive/datatype-boolean.html

 regards
 Tomas


Well... no.

In the link you've provided there is something different:


Valid literal values for the true state are:

TRUE't''true''y''yes''on''1'

so I could use 'true'... and this doesn't work.

And SQL is not case sensitive... but I will check it for you anyway:

CREATE TRIGGER trig_x_2 BEFORE INSERT ON x FOR EACH ROW EXECUTE PROCEDURE
trigger_x(TRUE);

ERROR:  syntax error at or near TRUE
LINE 1: ... INSERT ON x FOR EACH ROW EXECUTE PROCEDURE trigger_x(TRUE);

regards
Szymon


Re: [HACKERS] potential bug in trigger with boolean params

2011-05-11 Thread Szymon Guz
On 11 May 2011 11:01, Andreas Joseph Krogh andr...@officenet.no wrote:

 På onsdag 11. mai 2011 kl 10:56:19 skrev t...@fuzzy.cz:
   Hi,
   I was trying to create a trigger with parameters. I've found a
 potential
   bug
   when the param is boolean.
  
   Here is code replicating the bug:
  
   CREATE TABLE x(x TEXT);
  
   CREATE OR REPLACE FUNCTION trigger_x() RETURNS TRIGGER AS $$
   BEGIN
   RETURN NEW;
   END; $$ LANGUAGE PLPGSQL;
  
   CREATE TRIGGER trig_x_text BEFORE INSERT ON x FOR EACH ROW EXECUTE
   PROCEDURE
   trigger_x('text');
   CREATE TRIGGER trig_x_int BEFORE INSERT ON x FOR EACH ROW EXECUTE
   PROCEDURE
   trigger_x(10);
   CREATE TRIGGER trig_x_float BEFORE INSERT ON x FOR EACH ROW EXECUTE
   PROCEDURE trigger_x(42.0);
   CREATE TRIGGER trig_x_bool BEFORE INSERT ON x FOR EACH ROW EXECUTE
   PROCEDURE
   trigger_x(true);
  
   ERROR:  syntax error at or near true
   LINE 1: ... INSERT ON x FOR EACH ROW EXECUTE PROCEDURE trigger_x(true);
 
  The docs clearly state what the valid values are and the literal 'true'
 is
  not one of them (TRUE is). See this:
 
  http://www.postgresql.org/docs/9.0/interactive/datatype-boolean.html

 What are you trying to accomplish? CREATE OR REPLACE FUNCTION trigger_x()
 does not declare any formal-parameters, so calling it with arguments doesn't
 make sense. I'm surprised creating the other triggers didn't produce an
 error stating No function defined with the name trigger_ix and the given
 argument-type.


That's how you define trigger function. Later you can use params when
defining trigger.

regards
Szymon


Re: [HACKERS] potential bug in trigger with boolean params

2011-05-11 Thread Szymon Guz
On 11 May 2011 12:06, Andres Freund and...@anarazel.de wrote:


 Why do you wan't to use a boolean directly if you can't use it as the type
 itself anyway?


Yep, and this is a really good point :)
I wanted to have consistent api, so use true when I have a boolean value.
I will use 'true' and add some info on that to the procedure documentation.

regards
Szymon


Re: [HACKERS] Transaction-scope advisory locks

2010-12-13 Thread Szymon Guz
On 13 December 2010 23:52, Marko Tiikkaja marko.tiikk...@cs.helsinki.fiwrote:

 Hi,

 I often find myself wanting advisory locks that are automatically released
 when the transaction ends, so here's a small patch trying to do just that.
  I don't know much about the lock system so the patch is in the state it
 looks like this would work.  Any comments on the technical details are
 welcome.  There's obviously a lot of documentation and READMEs to change
 too, but I thought I'd see what people think about the idea before going
 there.

 So, thoughts?



In my opinion changing current behavior is not a good idea. I know some
software that relies on current behavior and this would break it. Maybe add
that as an option, or add another type of advisory lock?

regards
Szymon


Re: [HACKERS] temporary functions (and other object types)

2010-11-05 Thread Szymon Guz
On 5 November 2010 20:36, Alvaro Herrera alvhe...@alvh.no-ip.org wrote:

 Hi,

 A customer of ours has the need for temporary functions.  The use case
 is writing test cases for their databases: the idea being that their
 code creates a temp function which then goes away automatically at
 session end, just like a temp table.  It's said that this makes things
 generally easier for the test harness.

 Other object types that would also be useful to have as temp-able are
 types, domains and casts; and perhaps (if someone sees a need)
 aggregates and operators.  Other objects are not necessary, but if
 someone thinks that some more stuff should be made temp-able, we'd try
 to go for as general a solution as possible.  But these aren't critical;
 functions are the main pain point.

 I haven't looked at the code at all to see how this would be
 implemented; I'm basically asking whether there would be objections to
 having this feature in core.


Hi,
is that possible to create all that in one transaction? You could then make
rollback and all objects will just disappear.

regards
Szymon


Re: [HACKERS] Get the offset of a tuple inside a table

2010-09-21 Thread Szymon Guz
On 21 September 2010 23:02, Pei He hepeim...@gmail.com wrote:

 Hi,
 When I using an index scan, can I get the offset of the tuple in the table?

 Thanks
 --
 Pei


What do you mean by the offset in the table?