On Thu, Jun 18, 2015 at 8:07 PM, Eric Ridge eeb...@gmail.com wrote:
According to pg_proc.probin, all 32 of my C language functions point
to $libdir/my_extension_lib,
That's a damn lie. The deployment server has a number of databases
that have this extension installed and some of them have
On Thu, Jun 18, 2015 at 4:42 PM, Andres Freund and...@anarazel.de wrote:
How does your _PG_init() actually look like?
static ExecutorStart_hook_type prev_ExecutorStartHook = NULL;
static ExecutorEnd_hook_type prev_ExecutorEndHook = NULL;
void _PG_init(void)
{
prev_ExecutorStartHook =
I've written an extension that hooks ExecutorStart_hook and
ExecutorEnd_hook. The hooks are assigned in _PG_init() (and the previous
ones saved to static vars) and reset to the previous values in _PG_fini().
Maybe also of interest is the extension library is set in postgresql.conf
as a
Hi,
On 2015-06-18 16:36:17 -0400, Eric Ridge wrote:
I've written an extension that hooks ExecutorStart_hook and
ExecutorEnd_hook. The hooks are assigned in _PG_init() (and the previous
ones saved to static vars) and reset to the previous values in _PG_fini().
Maybe also of interest is the
Eric Ridge eeb...@gmail.com writes:
On Thu, Jun 18, 2015 at 4:42 PM, Andres Freund and...@anarazel.de wrote:
How does your _PG_init() actually look like?
static ExecutorStart_hook_type prev_ExecutorStartHook = NULL;
static ExecutorEnd_hook_type prev_ExecutorEndHook = NULL;
void
I wrote:
Eric Ridge eeb...@gmail.com writes:
As a data point, that might be interesting to know, but I'd still be
scratching my head about how it happened. Postgres doesn't load an
extension library more than once per backend session, does it?
It's not supposed to, and AFAICS
On Thu, Jun 18, 2015 at 5:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If that's broken, then so are most of our contrib modules.
Certainly none of them have an extra check as suggested by Andres.
I'm putting it in anyways, along with a guard in the actual hook
function to ERROR if prev_hook ==
On Thu, Jun 18, 2015 at 5:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, if it didn't occur to you already --- next time you see this,
you could try examining dfmgr.c's DynamicFileList data structure
using gdb. That might help illuminate what Postgres thinks it
loaded and why.
Hmm, okay.
Eric Ridge eeb...@gmail.com writes:
On Thu, Jun 18, 2015 at 5:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
As a data point, that might be interesting to know, but I'd still be
scratching my head about how it happened. Postgres doesn't load an
extension library more than once per backend session,
On Thu, Jun 18, 2015 at 6:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
What we were expecting I guess is that such functions would be declared
to reference the library underneath $libdir/plugins, not that you'd use
a symlink.
According to pg_proc.probin, all 32 of my C language functions point
I had this code in a script:
UPDATE food_foods SET included=true WHERE verification_status = 'I';
UPDATE food_foods SET included=false WHERE verification_status IS NULL;
I tried replacing it with:
UPDATE food_foods SET included=(verification_status = 'I');
However, that set included to true
On Mon, Jan 30, 2006 at 04:44:21PM +0800, Christopher Kings-Lynne wrote:
I had this code in a script:
UPDATE food_foods SET included=true WHERE verification_status = 'I';
UPDATE food_foods SET included=false WHERE verification_status IS NULL;
I tried replacing it with:
UPDATE food_foods
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I tried replacing it with:
UPDATE food_foods SET included=(verification_status = 'I');
However, that set included to true only where verification_status=I, it
didn't set false at all.
You'd have gotten NULL, not FALSE, at the rows where
Why doesn't this work:
test=# select oid, relname, indisclustered from pg_index join pg_class
on indexrelid=oid where indexrelid 17205;
ERROR: column oid does not exist
I'm _joining_ on the oid column.
If I qualify it, it works:
test=# select pg_class.oid, relname, indisclustered from pg_index
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Why doesn't this work:
test=# select oid, relname, indisclustered from pg_index join pg_class
on indexrelid=oid where indexrelid 17205;
ERROR: column oid does not exist
The JOIN is a bit like a view --- it doesn't have any system columns.
I just ran across this recent example:
If you perform the following, you get a truncated input:
test=# create table example (type char(5) NOT NULL);
CREATE
test=# insert into example VALUES ('VOLUME');
INSERT 156884 1
test=# select * from example;
type
---
VOLUM
(1 row)
However, if you
"Christopher Kings-Lynne" [EMAIL PROTECTED] writes:
Is this correct behaviour? Perhaps it is, as CHECK is checking the
truncated value - but I just want to make sure it's not a bug!
I think some people feel that we ought to raise an error rather than
silently truncating the input. However,
17 matches
Mail list logo
