-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 longe
-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
> dcbf
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 a/doc/sr
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 "n
Peter Eisentraut 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 some reason
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) bet
Craig Ringer 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 variables
>> wouldn't
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
Peter Eisentraut 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 funcname(PG_FUNCTION_ARGS);
> PGDL
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 (e
On 2014-02-17 10:30:16 -0300, Alvaro Herrera wrote:
> Tom Lane wrote:
> > Peter Eisentraut 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 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
Peter Eisentraut 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 provided on
On 2/15/14, 10:22 AM, Tom Lane wrote:
> Peter Eisentraut 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 patc
Peter Eisentraut 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 who
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
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 (p
Hi,
On 2014-01-15 00:41:41 -0500, Tom Lane wrote:
> Peter Eisentraut 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 .
> > E
Peter Eisentraut 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 discussed in t
Robert Haas writes:
> On Sun, Sep 1, 2013 at 10:36 AM, Stefan Kaltenbrunner
> 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 approach is actually sane.
> This patch h
* 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 ob
On 09/03/2013 06:15 PM, Robert Haas wrote:
> On Sun, Sep 1, 2013 at 10:36 AM, Stefan Kaltenbrunner
> 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 t
On Sun, Sep 1, 2013 at 10:36 AM, Stefan Kaltenbrunner
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
>> ProcessGUCArray, but sh
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 writes:
While working on upgrading the database of the search system on
postgresql.org to 9.2 I noticed that the dump
* Stefan Kaltenbrunner (ste...@kaltenbrunner.cc) wrote:
> On 08/18/2013 05:40 PM, Tom Lane wrote:
> > Stefan Kaltenbrunner 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
On 08/18/2013 05:40 PM, Tom Lane wrote:
> Stefan Kaltenbrunner 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 o
On 08/18/2013 05:40 PM, Tom Lane wrote:
> Stefan Kaltenbrunner 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 o
Stefan Kaltenbrunner 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 TEXT SEARCH CONFIGURAT
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 T
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/postgr
Pam Withnall <[EMAIL PROTECTED]> writes:
> When i call the function from sql
> SELECT sptest3(4) AS x;
> I get the error:
> "NOTICE: plpgsql: ERROR during compile of sptest3 near line 1
> "RROR: parse error at or near "
The message looks just like that, eh? I bet it's unhappy because your
fun
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 tr
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
33 matches
Mail list logo
