public.commandprompt.com: Issueshttps://public.commandprompt.com/https://public.commandprompt.com/favicon.ico?16484970162014-05-11T09:24:00Zpublic.commandprompt.com
Redmine postgres_fdw - Bug #5303 (New): [SPAM] Good shoes good priceshttps://public.commandprompt.com/issues/53032014-05-11T09:24:00ZAlvherre -dntnmh@dng.vnn.vnPL/php - Bug #5260 (New): The function could not return varchar string -- When there is function ...https://public.commandprompt.com/issues/52602011-11-02T23:16:35Zanthony chenzhihong.chen.cn@gmail.com
<p>There is pl/php definition as attached plsimple.sql. Which include other files blank.php.</p>
<p>Run first time:<br />test=# select plsimple();<br /> plsimple<br />----------</p>
<p>(1 row)</p>
<p>test=#<br />Run second time:<br />test=# select plsimple();<br /> plsimple<br />--------------<br /> Hello world!<br />(1 row)</p>
<p>When remove the definition of function test() in the blank.php, the issue disppears.</p> PL/php - Bug #5258 (New): Get rid of the trusted PL/PHPhttps://public.commandprompt.com/issues/52582011-05-27T05:43:07ZAlexey Klyukinalexk@commandprompt.com
<p>Apparently, the trusted PL/PHP has lots of security problems due to its trusted status, from sharing the same interpreter with an untrusted one, to <br />the fact that the trusted implementation relies on PHP safe mode, which is deprecated and allows some 'untrusted' (in PG's sense) operations, i.e. filesystem/network access. ATM we need to get rid of PL/PHP and leave only PL/PHPU implementation.</p> PL/php - Bug #5255 (New): support TRUNCATE triggershttps://public.commandprompt.com/issues/52552011-05-21T16:29:20ZÁlvaro Herreraalvherre@commandprompt.com
<p>$SUBJECT</p> PL/php - Bug #5225 (New): Unable to build PL/php on OS X (PHP 5.3)https://public.commandprompt.com/issues/52252010-06-29T05:25:59ZAlexey Klyukinalexk@commandprompt.com
<p>On OS X embed is built as a bundle instead of a library, making it impossible to link against it.</p>
<p>I've submitted the problem to the PHP project:<br /><a class="external" href="http://bugs.php.net/bug.php?id=48318">http://bugs.php.net/bug.php?id=48318</a></p>
<p>Still, it's not possible to build PL/php at the moment on this platform.</p> Pggraph - Bug #4950 (New): Write unit testshttps://public.commandprompt.com/issues/49502008-07-17T17:02:20ZAurynn Shawashaw@commandprompt.com
<p>This is pretty obvious</p> Pggraph - Bug #4949 (New): Document behaviourhttps://public.commandprompt.com/issues/49492008-07-17T16:59:08ZAurynn Shawashaw@commandprompt.com
<p>When date start and date end are used, it defaults to the range behavior.</p>
<p>When neither are selected, it defaults to the previous behavior, which is now() - interval time.</p> Pggraph - Bug #4948 (New): in pggraph_table, prevent crash if no tables presenthttps://public.commandprompt.com/issues/49482008-07-16T21:42:46ZAurynn Shawashaw@commandprompt.com
<p>If a given database doesn't have any tables, and it is the default in pggraph_table.py, then we need to catch that and switch to a different database/datname.</p> Pggraph - Bug #4947 (New): Do testing of data arrayshttps://public.commandprompt.com/issues/49472008-07-16T21:01:03ZAurynn Shawashaw@commandprompt.com
<p>While generating date range pages, we should test the length of each return set, so that we can trim out offsets that are going to be no-shows.</p>
<p>This is going to be kind of expensive to do for every page refresh, but I feel it's <br />worthwhile.</p>
<p>Alternatively, just have "NO DATA" splayed over the image in the event that there's no data.</p>
<p>How should we approach this?</p> Pggraph - Bug #4945 (New): Force all graphs to abort if non-specific data specifiedhttps://public.commandprompt.com/issues/49452008-07-15T15:32:45ZAurynn Shawashaw@commandprompt.com
<p>For all graphs, prevent date ranges from working if:</p>
<ul>
<li>High-level, multi-graph pages would be generated normally</li>
<li>Non-specific data is passed to the graphing function.
<ul>
<li>For pggraph_database, it REQUIRES a datname</li>
<li>For pggraph_table, it requires a datname, a tablename and a schemaname</li>
<li>For pggraph_index, it requires a datname, an indexname, and a schemaname</li>
</ul></li>
</ul> Pggraph - Bug #4943 (New): Future Planning and Ideashttps://public.commandprompt.com/issues/49432008-07-14T11:32:17ZAurynn Shawashaw@commandprompt.com
<ul>
<li>Javascript+SVG-based graphs, based on example code Darcy showed off a while back. This would allow us to do offset-based graphs (clicking an offset of, say, 5 days scrolls it back in time that far), as well as the ability to do click & drag ala the Google Maps interface.</li>
</ul> Pggraph - Bug #4940 (New): Remove prefixeshttps://public.commandprompt.com/issues/49402008-07-14T11:05:46ZAurynn Shawashaw@commandprompt.com
<p>As we are moving to a schema'd design, remove the prefix additions from the code and all new installations.</p>
<p>This involves a plpgsql function signature change.</p> Pggraph - Bug #4937 (New): Modification of DB Client code for date rangeshttps://public.commandprompt.com/issues/49372008-07-14T10:45:13ZAurynn Shawashaw@commandprompt.com
<p>The client code needs to be modified to take advantage of the new date range function signatures.</p>
<p>This will require:</p>
<ul>
<li>Modification of the functions that call the DB functions.
<ul>
<li>Ideally (and this will be a new ticket) I'd like to write the transparent python->db function mapper (obj.func(arg,arg) gets seamlessly converted to SELECT * FROM func(arg,arg))</li>
</ul></li>
</ul> Pggraph - Bug #4936 (New): Modify averaging functionshttps://public.commandprompt.com/issues/49362008-07-14T10:11:55ZAurynn Shawashaw@commandprompt.com
<p>All plpgsql functions will need two new arguments, and one removed argument:</p>
<p>start DATE, end DATE, and removal of offset INT.</p>
<p>The functions will be altered in the following ways:</p>
<ul>
<li>Determining the length of the WHILE loop from the date ranges, if present, instead of using the interval to calculate it.</li>
<li>Alter the queries to use the start DATE parameter to position the start of the set, and then utilize the WHILE loop to offset from that point, ie, WHERE date = date_start + (interval * iterations)::interval</li>
</ul> PL/php - Bug #4972 (In Progress): array PHP <-> Pg conversion is brokenhttps://public.commandprompt.com/issues/49722005-11-23T11:48:44ZÁlvaro Herreraalvherre@commandprompt.com
<p>Element parsing in arrays can easily be confused. Test case:</p>
<pre>
create or replace function another_text_test(text[], int)
returns text language plphp as $$ return $argsr0[$argsr1]; $$;
</pre>
<p>Strings should be quoted before passing them to PHP, so the NOTICE from PHP here is bogus:</p>
<pre>
pl_regression=# select another_text_test($${"foo",'bar', "{"}$$, 0);
NOTICE: plphp: Use of undefined constant foo - assumed 'foo'
another_text_test
-------------------
foo
(1 fila)
</pre>
<p>The same reason causes this to "eat" the inner level of quotes:</p>
<pre>
pl_regression=# select another_text_test($${"'bar'", "{"}$$, 0);
another_text_test
-------------------
bar
(1 fila)
</pre>
<p>Note particularly this totally unexpected behavior:</p>
<pre>
pl_regression=# select another_text_test($${"'bar'", "{"}$$, 1);
another_text_test
-------------------
array(
(1 fila)
</pre>