Re: [HACKERS] Help needed for PL/Ruby
On 29 April 2015 at 21:45, Szymon Guz wrote: > Hi Devrim, > I will take a look at this. > > regards, > Szymon > > On 29 April 2015 at 18:24, Devrim Gündüz 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] Help needed for PL/Ruby
Hi Devrim, I will take a look at this. regards, Szymon On 29 April 2015 at 18:24, Devrim Gündüz 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 > > -- Szymon
Re: [HACKERS] printing table in asciidoc with psql
On 14 November 2014 20:57, Alvaro Herrera 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
On 30 October 2014 09:04, Pavel Stehule wrote: > > > 2014-10-29 12:23 GMT+01:00 Szymon Guz : > >> >> >> On 17 October 2014 09:01, Pavel Stehule 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,>> | >>> ^| +++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
On 17 October 2014 09:01, Pavel Stehule 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, |
> ^| +++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
aligned, wrapped,
html,
latex (uses tabular),
- latex-longtable, or
- troff-ms.
+ latex-longtable,
+ troff-ms, or asciidoc.
Unique abbreviations are allowed. (That would mean one letter
is enough.)
@@ -2120,7 +2120,8 @@ lo_import 152801
The html, latex,
- latex-longtable, and troff-ms
+ latex-longtable, troff-ms,
+ and asciidoc
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 */
+ if (!opt_tuples_only && cont->title)
+ {
+ fputs(".", fout);
+ fputs(cont->title, fout);
+ fputs("\n", fout);
+ }
+
+/* print table [] header definition */
+ fputs("[options=\"header\",
Re: [HACKERS] printing table in asciidoc with psql
On 17 September 2014 19:55, Szymon Guz wrote:
>
>
> On 17 September 2014 19:30, Peter Eisentraut 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
aligned, wrapped,
html,
latex (uses tabular),
- latex-longtable, or
- troff-ms.
+ latex-longtable,
+ troff-ms, or asciidoc.
Unique abbreviations are allowed. (That would mean one letter
is enough.)
@@ -2120,7 +2120,8 @@ lo_import 152801
The html, latex,
- latex-longtable, and troff-ms
+ latex-longtable, troff-ms,
+ and asciidoc
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 pla
Re: [HACKERS] printing table in asciidoc with psql
On 17 September 2014 19:30, Peter Eisentraut 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
[HACKERS] printing table in asciidoc with psql
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" : "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", fout);
+ }
+
+
Re: [HACKERS] PL/pgSQL 2
On 3 September 2014 01:08, Jan Wieck 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
Re: [HACKERS] potential bug in psql
On 22 August 2014 17:06, Tom Lane wrote: > Szymon Guz 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
[HACKERS] potential bug in psql
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] Storing the password in .pgpass file in an encrypted format
On 21 February 2014 13:49, firoz e v 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
On 21 November 2013 21:15, Szymon Guz wrote: > > > > On 21 November 2013 20:20, Pavel Stehule 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 >> >>> On 21 November 2013 08:09, Pavel Stehule 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 > 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
Re: [HACKERS] new unicode table border styles for psql
On 21 November 2013 20:20, Pavel Stehule 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 > >> On 21 November 2013 08:09, Pavel Stehule 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
On 21 November 2013 08:09, Pavel Stehule 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] Clang support
On 19 November 2013 23:02, Szymon Guz wrote: > On 19 November 2013 22:54, Kevin Grittner wrote: > >> Szymon Guz 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] Clang support
On 19 November 2013 22:54, Kevin Grittner wrote: > Szymon Guz 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
[HACKERS] Clang support
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] How to create read-only view on 9.3
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
On 12 August 2013 18:37, Peter Eisentraut 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
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
Re: [HACKERS] ToDo: possible more rights to database owners
On 29 July 2013 13:20, Pavel Stehule wrote: > 2013/7/29 Szymon Guz : > > On 29 July 2013 11:25, Pavel Stehule 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] ToDo: possible more rights to database owners
On 29 July 2013 11:25, Pavel Stehule 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
[HACKERS] potential bug in error message in with clause
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] [COMMITTERS] pgsql: PL/Python: Convert numeric to Decimal
On 7 July 2013 21:35, Peter Eisentraut 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] [COMMITTERS] pgsql: PL/Python: Convert numeric to Decimal
On 6 July 2013 17:58, Claudio Freire 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
> wrote:
> >
> > On 07/06/2013 01:52 AM, Claudio Freire wrote:
> >>
> >> On Sat, Jul 6, 2013 at 2:39 AM, Tom Lane wrote:
> >>>
> >>> Peter Eisentraut 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 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
Re: [HACKERS] [PATCH] Fix conversion for Decimal arguments in plpython functions
On 28 June 2013 22:29, Claudio Freire wrote:
> On Fri, Jun 28, 2013 at 5:14 PM, Steve Singer wrote:
> > On 06/27/2013 05:04 AM, Szymon Guz wrote:
> >>
> >> On 27 June 2013 05:21, Steve Singer >> <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] plpython implementation
On 30 June 2013 14:45, Andres Freund wrote:
> On 2013-06-30 14:42:24 +0200, Szymon Guz wrote:
> > On 30 June 2013 14:31, Martijn van Oosterhout 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] plpython implementation
On 30 June 2013 14:31, Martijn van Oosterhout 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
On 30 June 2013 14:13, Andrew Dunstan 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
[HACKERS] plpython implementation
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] [PATCH] Fix conversion for Decimal arguments in plpython functions
On 28 June 2013 22:14, Steve Singer 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
On 27 June 2013 05:21, Steve Singer 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
On 26 June 2013 22:08, Szymon Guz wrote: > On 26 June 2013 21:59, Peter Eisentraut 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
Re: [HACKERS] [PATCH] Fix conversion for Decimal arguments in plpython functions
On 26 June 2013 21:59, Peter Eisentraut 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] Add more regression tests for CREATE OPERATOR
On 26 June 2013 21:10, Josh Berkus 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] Add more regression tests for CREATE OPERATOR
On 26 June 2013 20:57, Szymon Guz wrote: > On 26 June 2013 20:55, Josh Berkus 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
On 26 June 2013 20:55, Josh Berkus 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] [PATCH] Fix conversion for Decimal arguments in plpython functions
On 26 June 2013 12:04, Ronan Dunklau 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] [PATCH] Fix conversion for Decimal arguments in plpython functions
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
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 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 > >> On 26 June 2013 01:40, Steve Singer 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] Add more regression tests for CREATE OPERATOR
OK, so I think this patch can be committed, I will change the status. thanks, Szymon On 26 June 2013 09:26, Robins Tharakan 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 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 wrote: >> >>> On 23 May 2013 00:34, Robins Tharakan 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
On 26 June 2013 01:40, Steve Singer 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] [PATCH] Fix conversion for Decimal arguments in plpython functions
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 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 > >> On 25 June 2013 05:16, Steve Singer 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_**Languages<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 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 real, double, and >>> numeric are converted to >>>Python Decimal. This type is imported >>> fromdecimal.Decimal. >>> >>> >>> 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. >>> >>> >>> >>> >>> >>>PostgreSQL real and doubleare converted >>> to >>>Python float. >>> >>> >>> >>> >>> >>>PostgreSQL numeric is converted to >>>Python Decimal. This type is imported from >>> decimal.Decimal. >>> >>> >>> >>> >> 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] [PATCH] Fix conversion for Decimal arguments in plpython functions
On 25 June 2013 05:16, Steve Singer 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_**Languages<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 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 real, double, and > numeric are converted to >Python Decimal. This type is imported > fromdecimal.Decimal. > > > 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. > > > > > >PostgreSQL real and doubleare converted to >Python float. > > > > > >PostgreSQL numeric is converted to >Python Decimal. This type is imported from > decimal.Decimal. > > > > 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
On 25 June 2013 05:16, Steve Singer 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] converting datum to numeric
On 25 June 2013 08:51, Pavel Stehule wrote: > Hello > > 2013/6/25 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? > > 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
[HACKERS] converting datum to numeric
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] is it bug? - printing boolean domains in sql/xml function
On 14 March 2013 03:45, Peter Eisentraut 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] [9.4 CF 1] The Commitfest Slacker List
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] Add regression tests for SET xxx
On 18 June 2013 17:29, Kevin Grittner wrote: > Szymon Guz 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 regression tests for SET xxx
On 18 June 2013 13:10, Michael Paquier wrote: > On Tue, Jun 18, 2013 at 7:01 PM, Szymon Guz 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
On 18 June 2013 02:33, Robins Tharakan 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 wrote: > >> On 26 May 2013 19:56, Robins Tharakan 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
On 26 May 2013 19:56, Robins Tharakan 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
Re: [HACKERS] Add more regression tests for CREATE OPERATOR
On 23 May 2013 00:34, Robins Tharakan 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
[HACKERS] [PATCH] Fix conversion for Decimal arguments in plpython functions
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] potential bug in JSON
On 28 May 2013 17:53, Josh Berkus 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] potential bug in JSON
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] storing plpython global pointer
On 28 May 2013 14:15, Jan Urbański 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] storing plpython global pointer
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] converting numeric to string in postgres code
On 28 May 2013 12:07, Pavel Stehule wrote: > Hello > > 2013/5/28 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? > > > > There is a numeric_out function, you can use it or look on their source > code > > result = DatumGetCString(DirectFunctionCall1(numeric_out, d)); > Thanks.
[HACKERS] converting numeric to string in postgres code
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] adding import in pl/python function
On 28 May 2013 01:55, Peter Eisentraut wrote: > On Mon, 2013-05-27 at 20:43 -0300, Claudio Freire wrote: > > On Mon, May 27, 2013 at 8:13 PM, Peter Eisentraut > 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
Re: [HACKERS] adding import in pl/python function
On 24 May 2013 21:46, Claudio Freire wrote:
> On Fri, May 24, 2013 at 4:22 PM, Szymon Guz 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] adding import in pl/python function
On 24 May 2013 21:14, Claudio Freire wrote: > On Fri, May 24, 2013 at 4:10 PM, Szymon Guz 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
[HACKERS] adding import in pl/python function
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] issues with dropped columns in plpgsql code again
On 7 May 2013 21:23, Pavel Stehule 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
On 27 February 2013 10:20, Miroslav Šimulčík wrote: > 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
On 31 October 2012 14:52, Pavel Stehule wrote: > tested on 9.3 > > Pavel > > 2012/10/31 Pavel Stehule : > > 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?
On 18 November 2011 23:26, Kevin Grittner wrote: > 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
On 4 November 2011 10:20, Miroslav Šimulčík 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
Re: [HACKERS] potential bug in trigger with boolean params
On 11 May 2011 12:06, Andres Freund 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] potential bug in trigger with boolean params
On 11 May 2011 11:01, Andreas Joseph Krogh wrote:
> På onsdag 11. mai 2011 kl 10:56:19 skrev :
> > > 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
On 11 May 2011 10:56, 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
[HACKERS] potential bug in trigger with boolean params
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] Transaction-scope advisory locks
On 13 December 2010 23:52, Marko Tiikkaja wrote: > 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)
On 5 November 2010 20:36, Alvaro Herrera 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
On 21 September 2010 23:02, Pei He 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"?
