-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/29/2015 04:46 PM, Joe Conway wrote:
On 06/14/2015 03:46 AM, Dean Rasheed wrote:
I think the docs for the LEAKPROOF option in
create_function.sgml ought to mention RLS as well as security
barrier views. Also the current text is no longer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/14/2015 03:46 AM, Dean Rasheed wrote:
I think the docs for the LEAKPROOF option in create_function.sgml
ought to mention RLS as well as security barrier views. Also the
current text is no longer strictly correct in light of commit
I think the docs for the LEAKPROOF option in create_function.sgml
ought to mention RLS as well as security barrier views. Also the
current text is no longer strictly correct in light of commit
dcbf5948e12aa60b4d6ab65b6445897dfc971e01. Suggested rewording
attached.
Regards,
Dean
diff --git
On 04/15/2014 10:17 PM, Tom Lane wrote:
I actually think we should *add* a LIBPQEXPORT that handles this for
libpq, much like PGDLLEXPORT does for postgres(.exe). And in the
process, rename PGDLLEXPORT to POSTGRESEXPORT or PGSERVEREXPORT or
something.
My reaction to that is not bloody
On 04/15/2014 03:39 AM, Tom Lane wrote:
I still wish we could get rid of this problem by fixing the Windows build
recipes so that the PGDLLEXPORT marking wasn't needed. We proved to
ourselves recently that getting rid of PGDLLIMPORT on global variables
wouldn't work, but I'm not sure that the
Craig Ringer cr...@2ndquadrant.com writes:
On 04/15/2014 03:39 AM, Tom Lane wrote:
I still wish we could get rid of this problem by fixing the Windows build
recipes so that the PGDLLEXPORT marking wasn't needed. We proved to
ourselves recently that getting rid of PGDLLIMPORT on global
On 4/14/14, 3:28 PM, Peter Eisentraut wrote:
On 4/4/14, 10:07 AM, Andres Freund wrote:
If
somebody previously tried to do the correct thing and attached
PGDLLEXPORT to their own *function* prototoype, it would cause problems
now.
What is the difference (on affected platforms) between
Peter Eisentraut pete...@gmx.net writes:
Let me point out again that my patch doesn't actually do anything about
PGDLLEXPORT or the like. It just adds automatic prototypes into
PG_FUNCTION_INFO_V1, to reduce compiler warnings in extensions and
reduce some boilerplate in general.
Hmm ... for
On 4/4/14, 10:07 AM, Andres Freund wrote:
If
somebody previously tried to do the correct thing and attached
PGDLLEXPORT to their own *function* prototoype, it would cause problems
now.
What is the difference (on affected platforms) between
Datum funcname(PG_FUNCTION_ARGS);
and writing
Peter Eisentraut pete...@gmx.net writes:
What is the difference (on affected platforms) between
Datum funcname(PG_FUNCTION_ARGS);
and writing (effectively)
PGDLLEXPORT Datum funcname(PG_FUNCTION_ARGS);
Datum funcname(PG_FUNCTION_ARGS);
or for that matter
Datum
On 2014-02-17 10:30:16 -0300, Alvaro Herrera wrote:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On 2/15/14, 10:22 AM, Tom Lane wrote:
Yes it does; people who fail to remove their manual externs will get
Windows-only build failures (or at least warnings; it's not very clear
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On 2/15/14, 10:22 AM, Tom Lane wrote:
Yes it does; people who fail to remove their manual externs will get
Windows-only build failures (or at least warnings; it's not very clear
which declaration will win).
The manual externs
Hi,
On 2014-01-15 00:41:41 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
This idea has appeared at least twice now, in
http://www.postgresql.org/message-id/1386301050.2743.17.ca...@vanquo.pezone.net
and http://www.postgresql.org/message-id/52d25aa2.50...@2ndquadrant.com
On 2/15/14, 8:51 AM, Andres Freund wrote:
Based on those comments and the lack of counter arguments after a month
I am going to mark the patch as rejected.
Actually, I was waiting for that PGDLLIMPORT thread to sort itself out
before tackling this.
--
Sent via pgsql-hackers mailing list
On 1/15/14, 12:41 AM, Tom Lane wrote:
Meh. I don't think that extension authors are really going to appreciate
changing from thou shalt declare all thy functions to thou shalt
declare none of them.
This patch does no such thing.
If the code were such that it wouldn't matter
whether a
Peter Eisentraut pete...@gmx.net writes:
On 1/15/14, 12:41 AM, Tom Lane wrote:
Meh. I don't think that extension authors are really going to appreciate
changing from thou shalt declare all thy functions to thou shalt
declare none of them.
This patch does no such thing.
Yes it does; people
On 2/15/14, 10:22 AM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On 1/15/14, 12:41 AM, Tom Lane wrote:
Meh. I don't think that extension authors are really going to appreciate
changing from thou shalt declare all thy functions to thou shalt
declare none of them.
This patch
Peter Eisentraut pete...@gmx.net writes:
On 2/15/14, 10:22 AM, Tom Lane wrote:
Yes it does; people who fail to remove their manual externs will get
Windows-only build failures (or at least warnings; it's not very clear
which declaration will win).
The manual externs and the automatically
Peter Eisentraut pete...@gmx.net writes:
This idea has appeared at least twice now, in
http://www.postgresql.org/message-id/1386301050.2743.17.ca...@vanquo.pezone.net
and http://www.postgresql.org/message-id/52d25aa2.50...@2ndquadrant.com .
Even if it doesn't help with Windows issues, as
On Sun, Sep 1, 2013 at 10:36 AM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
It would seem that a simple solution would be to add an elevel argument
to ProcessGUCArray and then call it with NOTICE in the case that
check_function_bodies is true. None of the contrib modules call
On 09/03/2013 06:15 PM, Robert Haas wrote:
On Sun, Sep 1, 2013 at 10:36 AM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
It would seem that a simple solution would be to add an elevel argument
to ProcessGUCArray and then call it with NOTICE in the case that
check_function_bodies is
* Tom Lane (t...@sss.pgh.pa.us) wrote:
So I think a more reasonable fix is just to skip the ProcessGUCArray
call altogether when check_function_bodies = false, and to document
that validators mustn't assume anything about the GUC environment
when check_function_bodies = false.
If no
Robert Haas robertmh...@gmail.com writes:
On Sun, Sep 1, 2013 at 10:36 AM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
attached is a rough patch that does exactly that, if we are worried
about an api change we could simple do a ProcessGUCArrayNotice() in the
backbranches if that
On 09/01/2013 12:53 AM, Stephen Frost wrote:
* Stefan Kaltenbrunner (ste...@kaltenbrunner.cc) wrote:
On 08/18/2013 05:40 PM, Tom Lane wrote:
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
While working on upgrading the database of the search system on
postgresql.org to 9.2 I noticed
On 08/18/2013 05:40 PM, Tom Lane wrote:
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
While working on upgrading the database of the search system on
postgresql.org to 9.2 I noticed that the dumps that pg_dump generates on
that system are actually invalid and cannot be reloaded without
* Stefan Kaltenbrunner (ste...@kaltenbrunner.cc) wrote:
On 08/18/2013 05:40 PM, Tom Lane wrote:
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
While working on upgrading the database of the search system on
postgresql.org to 9.2 I noticed that the dumps that pg_dump generates on
Hi all!
While working on upgrading the database of the search system on
postgresql.org to 9.2 I noticed that the dumps that pg_dump generates on
that system are actually invalid and cannot be reloaded without being
hacked on manually...
Simple way to reproduce is using the following:
CREATE
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
While working on upgrading the database of the search system on
postgresql.org to 9.2 I noticed that the dumps that pg_dump generates on
that system are actually invalid and cannot be reloaded without being
hacked on manually...
CREATE
On 08/18/2013 05:40 PM, Tom Lane wrote:
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
While working on upgrading the database of the search system on
postgresql.org to 9.2 I noticed that the dumps that pg_dump generates on
that system are actually invalid and cannot be reloaded without
This is the second time I've had this happen in the last week or so. I have a 'regular' postgresql server running, and then test test setup (both llvm ang gcc). It's chewing up 1 core on my MBP, never completing.502 229 1 0 0:00.50 ?? 0:00.60 /Library/PostgreSQL/8.3/bin/postgres -D
I have installed plpgsql procedural language ok,
I could not get any functions to work.
I tried the most simple function as documented:
CREATE FUNCTION sptest3 (int4) RETURNS int4 AS
'BEGIN
RETURN $1+1;
END;' LANGUAGE 'plpgsql';
When i call the function from sql
What version are you using? On a 7.0.2 freebsd machine,
I cut and paste the below function and query and had
no problems.
Stephan Szabo
[EMAIL PROTECTED]
On Thu, 2 Nov 2000, Pam Withnall wrote:
I have installed plpgsql procedural language ok,
I could not get any functions to work.
I
32 matches
Mail list logo
