testing on them tomorrow if you are interested.
--
Regards
Petr Jelinek (PJMODOS)
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
without any errors (except for
start of course but thats known) - I think Tom had some doubts about it
after what he wrote in his first reply.
--
Regards
Petr Jelinek (PJMODOS)
and XP SP1 tested, builds and passes make check (except rules but
thats just different sorting of output in my locale and I always had
this problem - wiech is after wieck because 'ch' is character after 'h'
in my alphabet).
--
Regards
Petr Jelinek (PJMODOS)
---(end
library).
--
Regards
Petr Jelinek (PJMODOS)
---(end of broadcast)---
TIP 6: explain analyze is your friend
for this), but it's not adequate for building sources
from cvs.
--
Regards
Petr Jelinek (PJMODOS)
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
XHTML 1.0 ...
--
Regards
Petr Jelinek (PJMODOS)
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Tony Caduto napsal(a):
With there be a win32 version of beta2? or a beta1?
ftp://ftp.postgresql.org/pub/binary/v8.1beta/win32/
(join -hackers-win32 if you want to be informed about win32 specific stuff)
--
Regards
Petr Jelinek (PJMODOS)
www.parba.cz
---(end
Tom Lane wrote:
The simple solution seems to be to add --no-locale to the initdb args in
pg_regress.sh.
Er ... what exactly does that do that setting LC_ALL=C doesn't?
Windows are ignoring locale enviroment variables so you can't do that
--
Regards
Petr Jelinek (PJMODOS
to build it from msys shell.
If you want to build cvs sources, you also need flex and bison.
--
Regards
Petr Jelinek (PJMODOS)
www.parba.cz
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
extension
--
Regards
Petr Jelinek (PJMODOS)
www.parba.cz
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through
Tom Lane wrote:
It'd be useful to look at what comparable functionality is offered by
other DBs besides MySQL. Anyone know what DB2 or Oracle have in this
area?
IIRC they both have MERGE.
--
Regards
Petr Jelinek (PJMODOS)
---(end of broadcast
FROM clause in
SELECT. So you could in theory do
MERGE INTO tablename USING (SELECT 1 AS myid) ON (tablename.id = myid) ...
But I am not sure if this is what you want.
--
Regards
Petr Jelinek (PJMODOS)
---(end of broadcast)---
TIP 2: Don't 'kill -9
that FROM clause isn't required in postgres).
--
Regards
Petr Jelinek (PJMODOS)
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
that keys, oracle gives error on many-to-one or many-to-many
relationship between the source and target tables.
--
Regards
Petr Jelinek (PJMODOS)
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http
(http://www.microsoft.com/windows/virtualpc/default.mspx)
--
Regards
Petr Jelinek (PJMODOS)
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do
...
There is EnumSystemLocales API function in Windows.
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
not rush with this.
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
with
the newer ones and gnuwin32, iirc)
No they have newest flex, but the whole thing is even more broken on
64bit then (old) cygwin version - it just exits without doing anything
and does not even report any errors.
--
Regards
Petr Jelinek (PJMODOS)
Andrew Dunstan napsal(a):
Petr Jelinek wrote:
Cygwin 1.7.0-52 (iirc) with flex works for me on x64 Vista.
Can you let me have the flex.exe and cygwin1.dll that I can try on a
virgin WinS2k3 64-bit box?
It will probably need to be configured with --disable-nls.
This is the version I
and it
worked fine too (except for missing stdbool.h in msvc which is no big deal).
The coding style compared to cJSON (or other libs I've seen) seems
closer to the style of PostgreSQL, it would however still require
pgindent run and maybe some minor adjustments.
--
Regards
Petr Jelinek (PJMODOS
this can (and
I am sure will be) used as, but for the datatype itself, it might be
better idea to use what's already there, unless it's somehow
incompatible of course.
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
consider leveraging PostgreSQL's regex support or
if it would be a bad fit/waste of time/slower/not worth it.
Regex ? What for ? You certainly don't need it for parsing, you have
good parser IMHO and regex would probably be all of the above.
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via
object
type would remove my biggest problem with how both patches are
implemented (I mentioned it few times in the previous discussion) so
from that standpoint it might be a good thing.
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
this to be
possible using standard SQL.
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
statement then I'll drop the effort.
And how do we want to filter default acls ?
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
default
privileges for different things than he can just create child roles with
different default privileges and use SET SESSION AUTHORIZATION to switch
between them.
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
.
So currently I see the next step being rewriting the patch for the ALTER
DEFAULT PRIVILEGES IN SCHEMA schemaname GRANT ... and leaving the
functionality itself unchanged (with the exception of having VIEW as
separate object which I will remove).
--
Regards
Petr Jelinek (PJMODOS)
for doing something completely different (which is the only way
they could break this).
--
Regards
Petr Jelinek (PJMODOS)
grantonall-20090810.diff.gz
Description: Unix tar archive
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
Petr Jelinek wrote:
I attached revised version of the patch. Changes, thoughts:
- SCHEMA is mandatory now
- removed VIEWS and GRANT ON VIEW since it looks like only me and
Stephen want it there
- the patch is now made so that adding new filters in the future won't
mean tearing of half
if user wants to run something often then
he should crate a function.
Otherwise this should be quite straightforward (I have working code
already).
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
separate compiler for inline functions or change the
existing one to accept the required info as parameters and fabricate
some of it when compiling inline function. I am unsure which one is the
preferred way.
--
Regards
Petr Jelinek (PJMODOS)
Tom Lane napsal(a):
Petr Jelinek pjmo...@pjmodos.net writes:
However there is one question about implementing it in plpgsql.
Currently, the compiler reads info directly from heap tuple, so I either
have to write separate compiler for inline functions or change the
existing one to accept
this at all since every one of those users with CREATE TABLE
privileges would have to also set same DEFAULT PRIVILEGES and the dba
would have no say in the matter.
I personally can see use cases for both but I don't really see any
reasonable way to have both at the same time.
--
Regards
Petr
test for plpgsql implementation.
--
Regards
Petr Jelinek (PJMODOS)
inlinepl-2009-08-28.diff.gz
Description: Unix tar archive
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
privilege on schema but it can
still be done, one just have to update default privileges every time
somebody is granted that privilege, and DBA can still have control over
it all.
Hopefully this will at least inspire some more discussion on the matter.
--
Regards
Petr Jelinek (PJMODOS
Jan Urbański napsal(a):
Petr Jelinek wrote:
So I've been working on solution with which I am happy with (does not
mean anybody else will be also though).
Hi Petr,
I'm reviewing this patch and after reading it I have some comments.
Unfortunately, when I got to the compiling part
goes for removing the requirement of
BEGIN ... END for example).
BTW, what happens with the current patch if you try to do a RETURN?
Throws same error as function defined with RETURNS void.
--
Regards
Petr Jelinek (PJMODOS)
objects instead of all objects.
Except for above two changes and the fact that it's against current
head, the patch is exactly the same.
Thanks again.
--
Regards
Petr Jelinek (PJMODOS)
grantonall-2009-09-21.diff.gz
Description: Unix tar archive
--
Sent via pgsql-hackers mailing list
;)
Having said all that, I'm moving the patch to Waiting on author.
I'll changed it back to needs review since I made quite a few changes
(per your review).
--
Regards
Petr Jelinek (PJMODOS)
defacl-2009-09-22.diff.gz
Description: Unix tar archive
--
Sent via pgsql-hackers mailing list
since we don't cache compiled functions.
But I am not sure so I basically copied it from standard function
compiler to be on safe side. I am sure commiter will comment on this :)
--
Regards
Petr Jelinek (PJMODOS)
inlinepl-2009-09-22.diff.gz
Description: Unix tar archive
--
Sent via pgsql
Tom Lane napsal(a):
Petr Jelinek pjmo...@pjmodos.net writes:
[ anonymous code blocks patch ]
I committed this after some editorialization. Aside from adding missing
CREATE LANGUAGE and pg_dump support, I didn't like the API for inline
handler functions. Passing just a C string
I made some more small adjustments - mainly renaming stuff after Tom's
comment on anonymous code blocks patch and removed one unused shared
dependency.
--
Regards
Petr Jelinek (PJMODOS)
defacl-2009-09-23.diff.gz
Description: Unix tar archive
--
Sent via pgsql-hackers mailing list (pgsql
Jan Urbański napsal(a):
Petr Jelinek wrote:
I made some more small adjustments - mainly renaming stuff after Tom's
comment on anonymous code blocks patch and removed one unused shared
dependency.
Hi,
the patch still has some issues with dependency handling:
postgres=# create role
anything (I don't think it's
a good idea to reassign default acls) it just spits warning with hint
what to do if user plans to drop the role.
--
Regards
Petr Jelinek (PJMODOS)
defacl-2009-09-24-2.diff.gz
Description: Unix tar archive
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Robert Haas napsal(a):
Abhijit,
If this patch looks good now, can you mark it Ready for Committer in
the CommitFest app? If there are any remaining issues, please post a
further review.
I believe he'll be out for two more days.
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql
Tom Lane wrote:
Petr Jelinek pjmo...@pjmodos.net writes:
[ latest version of DefaultACLs patch ]
I started looking through this patch, but found that it's not nearly
ready to commit :-(. The big missing piece is that there's no pg_dump
support for default ACLs. That's a bigger chunk
on new partition child tables.
Just FYI, this one is still hierarchical (database-schema-parent table).
--
Regards
Petr Jelinek (PJMODOS)
privileges is a good idea. I was thinking about
rejecting creation of conflicting default privileges but that would be
impossible to detect before object creation which is too late.
--
Regards
Petr Jelinek (PJMODOS)
if you have conflict in multiple filters user
specified you simply throw error.
--
Regards
Petr Jelinek (PJMODOS)
it anywhere else in the chain
when you are merging privileges as you proposed.
--
Regards
Petr Jelinek (PJMODOS)
Tom Lane napsal(a):
Petr Jelinek pjmo...@pjmodos.net writes:
That's how it works now actually, the problem is that when you grant
something in the chain you can't revoke it anywhere else in the chain
when you are merging privileges as you proposed.
To allow that, you have to have
pg_dump support (hopefully) and \ddp command for psql. Still no
tab competition though. I removed that GRANT DEFAULT PRIVILEGES
statement, changed user facing elog()s to ereport()s, and I changed
catalog name to singular.
--
Regards
Petr Jelinek (PJMODOS)
defacl-2009-09-30.diff.gz
Description
you have a bunch of nasty issues, including the prospect
of non-superusers being able to control the privileges granted on
objects that don't belong to them.
Also it's not really a problem since superuser or role admin can set
these for other roles.
--
Regards
Petr Jelinek (PJMODOS)
Robert Haas napsal(a):
On Thu, Oct 1, 2009 at 1:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Petr Jelinek pjmo...@pjmodos.net writes:
because it seems like merging privileges seems to be acceptable for most
(although I am not sure I like it, but I don't have better solution for
managing
Petr Jelinek napsal(a):
Robert Haas napsal(a):
I'm going to reiterate what I suggested upthread... let's let the
default, global default ACL contain the hard-wired privileges, instead
of making them hardwired. Then your objects will get those privileges
not because they are hard-wired
Tom Lane napsal(a):
Petr Jelinek pjmo...@pjmodos.net writes:
[ latest default-ACLs patch ]
Applied with a fair amount of editorial polishing. Notably I changed
the permissions requirements a bit:
Thank you very much Tom.
One thing that seems like it's likely to be an annoyance
Tom Lane napsal(a):
Petr Jelinek pjmo...@pjmodos.net writes:
Tom Lane napsal(a):
One thing that seems like it's likely to be an annoyance in practice
is the need to explicitly do DROP OWNED BY to get rid of pg_default_acl
entries for a role to be dropped.
Yeah I am not happy
on the OpenIntoRel().
That's strange behavior I agree. However I don't see how default ACLs
changed it in any way, owner could REVOKE his privileges before.
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Petr Jelinek napsal(a):
Tom Lane napsal(a):
Petr Jelinek pjmo...@pjmodos.net mailto:pjmo...@pjmodos.net writes:
Tom Lane napsal(a):
One thing that seems like it's likely to be an annoyance in practice
is the need to explicitly do DROP OWNED BY to get rid of pg_default_acl
entries
this patch doesn't apply cleanly anymore...
Fixed.
some comments:
1) in docs for REVOKE you're omitting the SCHEMA part of the new syntax.
Fixed.
2) i think that getNamespacesObjectsOids() could be rewritten in something like:
Right.
--
Regards
Petr Jelinek (PJMODOS)
grantonall
part when using it.
Regards
Petr Jelinek
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
record between the update and insert
and then another transaction could delete it between the insert and the
second update.
You know we have example in manual right ?
http://www.postgresql.org/docs/current/static/plpgsql-control-structures.html#PLPGSQL-UPSERT-EXAMPLE
:)
--
Regards
Petr Jelinek
is doing
could help or continue the work.
--
Regards
Petr Jelinek (PJMODOS)
diff --git a/src/backend/nodes/nodeFuncs.c b/src/backend/nodes/nodeFuncs.c
index 015dfdc..b2d17ab 100644
*** a/src/backend/nodes/nodeFuncs.c
--- b/src/backend/nodes/nodeFuncs.c
*** bool
*** 2354,2359
it for every object for
which we have GRANT command. Also in standard GRANT there is no
distinction between table and view, I guess in this case there should be.
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Petr Jelinek wrote:
Anyway back to my thoughts about this patch. First of all I see problem
with the proposed syntax. For this syntax I think TABLES (FUNCTIONS,
SEQUENCES, etc) would have to be added to keywords which is problematic
because there are views named tables, sequences, views
privileges, I added GRANT ON VIEW foo syntax which is more or less
synonymous to GRANT ON TABLE foo syntax. It felt weird to have GRANT ON
ALL VIEWS but not GRANT ON VIEW.
Any comments/suggestions are welcome (I especially wonder if the use of
list_union_ptr is acceptable).
--
Regards
Petr
to confusion.
It doesn't. I stated that I am not implementing the second part of the
TODO item in my first email specifically for this reason (the second
part was GRANT ON NEW TABLES).
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
.
Thanks.
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
between tables and views.
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
there is demand for this. Also to paraphrase you
Tom, by that logic you can tell people to write half of administration
functionality as plpgsql functions.
--
Regards
Petr Jelinek (PJMODOS)
Greg Stark wrote:
Isn't the answer to grant permissions to a role and then just put
people in that role?
Still have to give permissions at least to that role.
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Petr Jelinek wrote:
So, here is the first version of the patch.
Attached is v2 with slightly improved code, nothing has changed
feature-wise.
--
Regards
Petr Jelinek (PJMODOS)
diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml
index bf963b8..7ddbd25 100644
*** a/doc/src
at this moment.
Patch is against current Git HEAD (it is context diff).
--
Regards
Petr Jelinek (PJMODOS)
defaultacls.diff.gz
Description: Unix tar archive
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
of ACL_OBJECT_VIEW but on the other hand I don't like the idea of adding
another object type variable into GrantStmt struct which would be needed
if we adjusted GRANT ON ALL to Stephen Frost's method.
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
HEAD.
Thanks for your review.
--
Regards
Petr Jelinek (PJMODOS)
diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml
index bf963b8..51aad15 100644
*** a/doc/src/sgml/ref/grant.sgml
--- b/doc/src/sgml/ref/grant.sgml
*** PostgreSQL documentation
*** 23,39
synopsis
code inside aclchk.c which people didn't like. We can use
the changed GrantObjectType in DefaultACLs and filter inapplicable types
inside C code as I do in GRANT ON ALL patch and it's what I did
originally, but submitted version of DefaultACLs behaves differently.
--
Regards
Petr Jelinek (PJMODOS
One more typo fix in docs
--
Regards
Petr Jelinek (PJMODOS)
diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml
index bf963b8..6400f9e 100644
*** a/doc/src/sgml/ref/grant.sgml
--- b/doc/src/sgml/ref/grant.sgml
*** PostgreSQL documentation
*** 23,39
synopsis
to do that.
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
version of the patch per your comments. Let's hope I
didn't introduce new problems :)
Thanks for your time.
--
Regards
Petr Jelinek (PJMODOS)
defaultacls.diff.gz
Description: Unix tar archive
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
basic docs included (but you have to pardon my english as I didn't
pass it to Stephen for proofreading due to discovery of that bug).
--
Regards
Petr Jelinek (PJMODOS)
defaultacls-2009-07-19.diff.gz
Description: Unix tar archive
--
Sent via pgsql-hackers mailing list (pgsql-hackers
/2009-07/msg00957.php ) and
I fear returned with feedback might prevent that until next commit fest.
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut wrote:
On Thursday 23 July 2009 06:26:05 Petr Jelinek wrote:
I'd still like to have opinion from one of the commiters on the
VIEW problem which also affects grant on all patch ( see
http://archives.postgresql.org/pgsql-hackers/2009-07/msg00957.php ) and
I fear returned
or
something (altho I don't have the slightest idea what could cause that)
? I run make check on patches using gcc under debian and msvc on vista
before sending them.
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
changes based solely
on my opinions of what sounds better and what's more consistent with the
existing documentation. Do with them as you see fit. :)
Applied with minor adjustments, attached updated patch.
--
Regards
Petr Jelinek (PJMODOS)
defaultacls-2009-07-26.diff.gz
Description: Unix
and rechecked with few dozen of real-world functions, and
it still looks good from my point of view. I made bit of adjustment of
english in new comments and Pavel sent me privately fix for proper
handling of languages that don't have checker function. Updated patch
attached.
Regards
Petr Jelinek
On 03/10/2012 04:36 PM, Pavel Stehule wrote:
and there some cleaned version
Reran my tests and adjusted docs a bit, tbh I considered the previous
versions way more useful but even in this form it's nice and useful
functionality.
Regards
Petr Jelinek
plpgsql_check_function2.diff.gz
am saying is that if some framework
(not the
framework's users!) wants to build something like that today its not all
that
complicated.
I would prefer to be able to detect this *before* the rewrite happens though
when writing tooling.
Regards
Petr Jelinek
--
Sent via pgsql-hackers mailing
(like me) in their tooling
this is also usable solution.
Regards
Petr Jelinek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
not easy to handle.
I thought the point of this was to call the trigger *before* anything
happens.
Regards
Petr Jelinek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Andres Freund
Sent: 06 December 2012 20:44
To: Petr Jelinek
Cc: 'Simon Riggs'; 'Robert Haas'; 'Dimitri Fontaine'; 'Josh Berkus';
pgsql-
hack...@postgresql.org
will those external
tools have to adjust.
Regards
Petr Jelinek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Pavel Stehule
Sent: 28 November 2012 11:07
To: Selena Deckelmann
Cc: PostgreSQL Hackers
Subject: Re: [HACKERS] plpgsql_check_function - rebase for 9.3
Hello
a
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Tom Lane
Sent: 26 January 2013 18:16
Subject: Re: [HACKERS] plpgsql_check_function - rebase for 9.3
Petr Jelinek pjmo...@pjmodos.net writes:
I was wondering
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: 26 January 2013 20:12
Subject: Re: [HACKERS] plpgsql_check_function - rebase for 9.3
I wrote:
[ pokes around... ] Hm, it appears that that does work on Linux,
because for some reason we're specifying
) opinion
overloading creates more problems than it solves. You're not going to
convince me that get() is *ever* a good name for a function - you might as
well call it thing() or foo() for all the useful information that name
conveys.
Let me join the minority here, +1
Regards
Petr Jelinek
plpgsql.extra_warnings and
plpgsql.extra_errors?
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On 18/03/14 13:43, Pavel Stehule wrote:
2014-03-18 13:23 GMT+01:00 Petr Jelinek p...@2ndquadrant.com
mailto:p...@2ndquadrant.com
Agree that compile_errors dos not make sense, additional_errors
and additional_warnings seems better, maybe plpgsql.extra_warnings
for some check. Maybe
shadow-variables-check
shadowed-variables would be a better name.
+1
Attached V4 uses shadowed-variables instead of shadow.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
diff --git a/doc/src
original patch, maybe I
should remove the word number there as it implies that there are a lot
of them, but I don't really want to change everything to singular when
the input is specified as list.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support
On 18/03/14 20:45, Pavel Stehule wrote:
2014-03-18 20:44 GMT+01:00 Petr Jelinek p...@2ndquadrant.com
mailto:p...@2ndquadrant.com:
On 18/03/14 20:36, Pavel Stehule wrote:
para
+To aid the user in finding instances of simple but common
problems before
1 - 100 of 1148 matches
Mail list logo
