Tom Lane wrote:
One way to deal with it would be to expose the whole renegotiation
setting as a user configuratble option. So they can set *when* we
renegotiate, which would also let them turn it off completely.
>>>
>>> Well, that might be a reasonable thing to do, because it's not
Mark Mielke wrote:
> On 01/29/2010 09:01 PM, Tom Lane wrote:
> > Maybe. We concluded in the April 2009 thread that
> > standard_conforming_strings = ON had gotten little or no field testing,
> > and I don't see any strong reason to hope that it's gotten much more
> > since then.
>
> Not to contra
Nicolas Barbier wrote:
>> I don't know if such a thing would be easy to implement in
>> PostgreSQL, but I had thought that the "standard" approach to
>> implement predicate locking is like this:
>>
>> Whenever you touch (read) a data structure, you tag it with a lock
>> that prevents anybody else f
Robert Haas wrote:
> Jeff Davis wrote:
> > I have a question regarding true serializability and predicate locking.
> > There's some context on the wiki page:
> >
> > If you have the following DDL:
> >
> > create table mytable(mycircle circle);
> > create index mytable_mycircle_idx on mytable
> >
Kevin Grittner wrote:
> Another interesting thing which crossed my mind (and I should
> probably add a section for such things in the wiki) is that, given
> the overhead and conflict implications of using table scans in
> serializable transactions, we should perhaps try to discourage table
> scans
Kevin Grittner wrote:
>> It seems to me that the hard part of this problem is to describe
>> the general mechanism by which conflicts will be detected, with
>> specific references to the types of data structures that will be
>> used to hold that information.
>
> Well, the general approach to tracki
Bruce Momjian wrote:
> I must be missing something but I thought the only problem with our
> existing snapshot system was that you could see a row updated after your
> snapshot was created, and that the solution to that was to abort the
> transaction that would see the new row. Can you tell me wha
Magnus Hagander wrote:
> On Wed, Dec 16, 2009 at 20:34, David E. Wheeler wrote:
> > *** a/doc/src/sgml/hstore.sgml
> > --- b/doc/src/sgml/hstore.sgml
>
> Heh, interesting. That clearly shouldn't be there. Applied.
Does this count as catch-22?
Yours,
Laurenz Albe
--
Sent via pgsql-hackers maili
Robert Haas wrote:
> > A predicate can include columns from an index plus others.
> > Am I missing something?
>
> Hmm, interesting point. In that case you couldn't use the index to
> enforce predicate locking under MVCC without disabling HOT. But there
> will be other cases where that wouldn't h
Nicolas Barbier wrote:
>> Quote:
[...]
>>
>> That sounds like it should actually work.
>
> That boils down to 2PL, using a granularity that is somewhere between
> table locks and single-row locks (note that the latter doesn't
> correctly enforce serializability, hence something more coarse which
>
Kevin Grittner wrote:
> Just to make those who care aware of it, here is Michael Cahill's
> Doctoral Thesis based on implementing Serializable Snapshot
> Isolation in InnoDB using a refined version of the techniques
> previously used in the Berkley DB (and previously discussed on this
> list):
>
abindra wrote:
> Next quarter I am planning to do an Independent Study course
> where the main objective would be to allow me to get familiar
> with the internals of Postgres by working on a project(s). I
> would like to work on something that could possibly be
> accepted as a patch.
>
> This
Peter Eisentraut wrote:
> When using the "service" parameter in a libpq connection (e.g., psql
> service=foo), and the service name is not defined in pg_service.conf,
> then the setting is silently ignored and the connection proceeds with
> whatever other settings and defaults apply. That does not
Tom Lane wrote:
> Applied with some minor modifications. Aside from the added valuntil
> parameter, I changed the "isencrypted" parameter to an int with some
> #define'd values. It seems easily foreseeable that we'll replace the
> MD5 encryption scheme someday, and it'd be good to ensure that thi
Itagaki Takahiro wrote:
> Looks good. I change status of the patch to "Ready for Committer".
Thanks for the help!
> BTW, it might not be a work for this patch, we also need to
> reject too long "VALID UNTIL" setting. If the password is
> complex, we should not use the same password for a long tim
Heikki Linnakangas wrote:
> I think it would better to add an explicit "isencrypted" parameter to
> the check_password_hook function, rather than require the module to do
> isMD5 on the password. Any imaginable check hook will need to know if
> the password is in MD5 format, and the backend already
Itagaki Takahiro wrote:
> I've reviewed your patch. The rough approach looks fine,
> but I have some comments about function declarations and coding style.
Thank you for taking the time!
I think I addressed all the shortcomings you mentioned with
the attached patches. I fixed the "{" alignment; I
KaiGai Kohei wrote:
> I'm uncertain how Oracle handles the condition on the statement
> triggers. But it seems to me WHEN clause on the statement triggers
> are nonsense.
SQL> CREATE TRIGGER dummy BEFORE DELETE ON employees WHEN (1 = 1)
2 BEGIN
3 END;
4 /
CREATE TRIGGER dummy BEFORE DELET
Tom Lane wrote:
>> The problem is that both _LARGE_FILES and _LARGE_FILE_API are #defined
>> in this case, which makes #include fail.
>> Does anyone have an idea how to best fix this problem in the
>> source tree? I'm willing to implement and test.
>
> I've committed changes for this in CVS, plea
I CC: this to the hackers list as it seems to be an old problem that
was never fixed. See at the bottom.
Alexandra Roy wrote:
> This is a summary of what I have noticed concerning
> PostgreSQL 8.3.8 compilation on AIX 5.3 TL9.
>
> 1. To do a successful 64-bit build, specify and execute:
>
>
>
Tom Lane wrote:
> > I wonder why backup_label isn't automatically removed
> > in normal crash recovery case.
>
> Removing it automatically could be catastrophic if done
> incorrectly, no?
>
> It would be no less catastrophic if done incorrectly from outside the
> postmaster; see for example the
Fujii Masao wrote:
> When a crash occurs before calling pg_stop_backup(),
> the subsequent crash recovery causes the FATAL error
> and outputs the following HINT message.
>
> If you are not restoring from a backup, try removing the file
> \"%s/backup_label\"."
>
> I wonder why backup_label is
Peter Eisentraut wrote:
>> I don't get why you need 'password' authentication for that.
>> The point where the password should be checked is not when
>> the user uses it to logon, but when he or she changes it.
>>
>> So in my opinion that should be:
>> This facility will require to send new and ch
Bruce Momjian wrote:
> Great, added to TODO:
>
> Allow server-side enforcement of password policies
>
> Password checks might include password complexity or non-reuse of
> passwords. This facility will require the client to send the password to
> the server in pl
Mark Mielke wrote:
> Does Oracle really do password checks on the base SQL commands used to
> change an Oracle password? That sounds silly.
In Oracle you can write a stored procedure to check passwords;
it is invoked whenever a user is created or altered.
No matter how you change the password, O
I wrote:
> Following the discussions in
> http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php
> and
> http://archives.postgresql.org/pgsql-hackers/2009-10/msg00025.php ,
> here are patches for
>
> a) a hook in backend/commands/user.c that allows one to add
>password checking func
Following the discussions in
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php
and
http://archives.postgresql.org/pgsql-hackers/2009-10/msg00025.php ,
here are patches for
a) a hook in backend/commands/user.c that allows one to add
password checking functions
b) a contrib module
Bruce Momjian wrote:
>Tom Lane wrote:
>> > That said, it would still be good to have something actually *useful*
>> > in contrib. A bit more than just comparing userid and password.
>> > Perhaps at least being able to set the min length, and the requirement
>> > on having >1 "character class"?
>>
>
Aidan Van Dyk wrote:
> Can we have the check password hook function called in both the
> plaintext/encrypted case, with a flag as to whether it's encrypted or
> not?
It will be called in both cases, and I figured that you can
check yourself the same way that PostgreSQL does:
If isMD5(password), th
Andrew Dunstan wrote:
>>> So here's the patch.
>>> I don't think there is documentation required;
>>> correct me if I am wrong.
>>
>> How will people know how to use it, or that it's even there without at
>> least a note in the docs somewhere?
>
> I'd prefer to have an example as a contrib module,
In the discussion following
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php
the consensus was that a hook that allows you to implement
a password checking routine as a module "would not hurt".
So here's the patch.
I don't think there is documentation required;
correct me if I am
Tom Lane wrote:
> > pgAdmin MD5's the passwords if you use the GUI to change them, or when
> > add a user. It doesn't make any attempt to parse the SQL if you enter
> > it yourself in the query tool though (nor is it going to).
>
> No, I wouldn't expect it to go that far. My point is just that
>
Tom Lane wrote:
> Actually there's a much bigger problem with asking the backend to reject
> weak passwords: what ya gonna do with a pre-MD5'd string? Which is
> exactly what the backend is going to always get, in a security-conscious
> environment.
You mean if the password is set with
CREATE/ALT
Dear hackers,
I have been thinking about ways to have PostgreSQL reject
weak passwords.
I think the standard recommendation is "use PAM and LDAP",
but that requires the user to change the password outside
of PostgreSQL. And who would want to setup and maintain an
LDAP server just for this?
Since
Tom Lane wrote:
> > I don't see any reason why not breaking the user visible behavior of
> > tuples CTID between any two major releases,
>
> > Am I completely wet here?
>
> Completely. This is a user-visible behavior that we have encouraged
> people to rely on, and for which there is no easy sub
Greg Stark wrote:
> If you use binary encoding then you don't have to deal with that.
> Though I seem to recall there is still a gotcha you have to worry
> about if there are nul bytes in your datum. I don't recall exactly
> what that meant you had to do though.
As far as I know, it only means tha
Tom Lane wrote:
>>> So I'd like to see an actual case made
>>> that there's a strong reason for not requiring FROM/IN in ecpg.
>>
>> I guess there's only one, compatibility.
>
> Yeah. Are there any other precompilers that actively reject FROM/IN
> here? If we're just a bit more strict than the
Tom Lane wrote:
>>> Is there a reason we force plpgsql IN parameters to constant?
>
> Now having said all that, I'm not really in favor of Steve's
> proposal --- it seems like it mostly would be encouraging dubious
> programming practices. But it's hard to say that the arguments
> against are mor
Tom Lane wrote:
>> I'd suggest that we publish an official policy, with the following dates
>> for "EOL":
>
> But on the whole I think we should NOT have such a policy, at all.
[...]
> If someone wants a guaranteed EOL date, they ought to be contracting
> with a commercial support company and pay
David E. Wheeler wrote:
> This code:
>
> CREATE OR REPLACE FUNCTION foo() returns boolean as $$
> DECLARE
> have_rec record;
> want_rec record;
> BEGIN
> have_rec := row(1, 2);
> want_rec := row(3, 5);
> RETURN have_rec IS DISTINCT FROM w
Tom Lane wrote:
> The code change is already made for RC1, but if you want to send in a
> patch to improve the docs, feel free. I left it with just a vague
> recommendation to update to the latest fixpack:
> http://developer.postgresql.org/pgdocs/postgres/installation-platform-notes.html#INSTALLAT
Tom Lane wrote:
>> On Thu, Jun 11, 2009 at 9:50 AM, Tom Lane wrote:
>>> Where are we on this?
>
>> waiting on a patch? Albe? (or should I do it myself?)
>
> I thought the proposed patch was just "remove the special case for AIX
> in src/backend/libpq/ip.c".
Yes.
The only bugs at IBM that are l
Merlin Moncure wrote:
> I wrote:
>> I can try, but I only have AIX 5.3 to test with, so I won't be able
>> to test for bugs in other versions.
>>
>> I would need to know what the problems with getaddrinfo on AIX are.
>>
>> I'll also try to investigate known bugs in AIX' getaddrinfo.
>>
>> AIX 4.3 h
Tom Lane wrote:
> Drat. Okay, that easy solution probably won't fly. Anyone with AIX
> access want to try to develop a patch that covers this case without
> breaking the other ones?
I can try, but I only have AIX 5.3 to test with, so I won't be able
to test for bugs in other versions.
I would n
Building 8.4beta2 on my AIX test machine works fine,
but when I set listen_addresses = '*' in postgresql.conf,
the server fails to start.
This is what I get:
LOG: 0: could not translate service "5432" to address: Hostname and
service name not provided or found
LOCATION: StreamServerPort, p
Kevin Grittner wrote:
>> 1. implementation of the paper's technique sans predicate locking,
>> that would avoid more serialization anomalies but not all?
>
> I saw that as a step along the way to support for fully serializable
> transactions. If covered by a "migration path" GUC which defaulted
Kevin Grittner wrote:
> > All the authors show with regard to predicate handling is
> > handwaving,
>
> That is because predicate locking is a mature technology with many
> known implementations. The best technique for any database product
> will depend on that product, and their technique doesn
Kevin Grittner wrote:
> > I still haven't actually read the paper so I should probably bow out
> > from the conversation until I do. I was apparently already under
> > one misapprehension as Laurenz just claimed the paper does not show
> > how to prevent "phantoms" (phantom reads I assume?). Perha
Kevin Grittner wrote:
> > What if there is an index on the "ishighlander" row?
> > Then an index scan would find only one candidate to examine,
> > and the other rows would not even be touched by the execution plan.
>
> I assume you're talking about this line of your function:
>
> SELECT coun
Kevin Grittner wrote:
> > Where does T1 select rows that were modified by T0? It selects only
> > one row, the one it modified itself, right?
>
> You have to select it to know whether to count it, right?
We are getting closer.
So an SIREAD lock is taken for every row that is examined during
the
Kevin Grittner wrote:
> > maybe I misunderstood something.
> >
> > Consider a function
> > "makehighlander(personid integer) RETURNS void"
> > defined like this:
> >
> >SELECT ishighlander INTO b FROM scots WHERE id=personid;
> >IF b THEN
> > RETURN; /* no need to do anything */
> >
Greg Stark wrote:
> > So I think one would have to add intention locks for rows considered
> > in the WHERE clause to guarantee true serializability.
>
> Does the paper explain how to deal with rows "considered" in the WHERE clause
> which don't yet exist? Ie, "SELECT count(*) WHERE foo" needs to
Kevin Grittner wrote:
> While discussing potential changes to PostgreSQL documentation of
> transaction isolation levels, Emmanuel Cecchet pointed out an
> intriguing new paper[1] on a new algorithm to provide true
> serializable behavior in a MVCC based database, with no additional
> blocking; alt
Tom Lane wrote:
> > The solution to this is to change the following line in
> > src/backend/postmaster/postmaster.c:
>
> We're not going to break a bunch of other applications in order to make
> some undocumented, unsupported Oracle thingie work (until they change
> it...). Got another solution?
Peter Eisentraut wrote:
>> I don't think that particular example is a good one since the whole
>> point of the archive is that it should be off-server. If we're going to
>> be exact about the example then we should give a more realistic one,
>> like using scp. Unfortunately, there is no secure-remo
Heikki Linnakangas wrote:
> > The documentation states
> >
> > "The archive command should generally be designed to refuse to overwrite
> > any pre-existing archive file."
> >
> > and suggests an archive_command like "test ! -f .../%f && cp %p .../%f".
> >
> > We ran into (small) problems with
The documentation states in
http://www.postgresql.org/docs/current/static/continuous-archiving.html#BACKUP-ARCHIVING-WAL
"The archive command should generally be designed to refuse to overwrite any
pre-existing archive file."
and suggests an archive_command like "test ! -f .../%f && cp %p .../%f
Tom Lane wrote:
>> I propose that this behaviour be changed such that 'terse' is ignored
>> for all log messages of FATAL or PANIC severity.
>> [ on the strength of a single example ]
>
[...]
>
> It seems like it might be better to rephrase error messages to ensure
> that anything really critical
Jonah H. Harris wrote:
I'd like to submit this for 8.4, but I want to ensure that -hackers
at large approve of this feature before starting serious coding.
>>>
>>> IMHO, this is a functionality that should be enabled by default (as it
>>> is on most other RDBMS). It would've prevented se
[what should happen if a smart shutdown request is received during online
backup mode?
I'll cc: the hackers list, maybe others have something to say to this]
Heikki Linnakangas wrote:
> Albe Laurenz wrote:
>> Moreover, if Shutdown == SmartShutdown, new connections won't
Greg Smith wrote:
> > 1) On "pg_ctl stop|restart -m smart", check if online backup is
> > in progress and do not shutdown in this case (treat the online
> > backup like an open connection).
>
> As long as you give a warning as to the cause. While you're in there, I
> think more output in gen
I'm referring to the discussion in this thread:
http://archives.postgresql.org/pgsql-hackers/2007-11/msg00946.php
As expressed in the thread, I think that there should not be
a backup_label file in the data directory after a clean shutdown,
because
a) it's probably an oversight anyway (someone for
Tom Lane wrote:
>> I'd like to extend the libpq service file by allowing
>> wildcards, e.g. like this:
>
>> [%]
>> host=dbhost.mycompany.com
>> dbname=%
>
>> Such an entry would match all service parameters,
>> and all ocurrences of the wildcard right of a = would
>> be replaced with the service
I'd like to extend the libpq service file by allowing
wildcards, e.g. like this:
[%]
host=dbhost.mycompany.com
dbname=%
Such an entry would match all service parameters,
and all ocurrences of the wildcard right of a = would
be replaced with the service parameter.
That implies that a [%] entry is
Gokulakannan Somasundaram wrote:
> Can you please explain, any specific use-case where DDLs are
> necessary within a transaction?
SQL-Scripts that create database objects and should either
succeed or have no effect.
Yours,
Laurenz Albe
---(end of broadcast)-
Simon Riggs wrote:
> On Wed, 2007-11-21 at 09:47 +, Peter Childs wrote:
>> How about this, emit a warning on shutdown and fail to shutdown until
>> the backup has finished.
>
> That would be reasonable for -m smart shutdown.
>
> We would then be treating the backup as a connection.
>
> ...bu
Simon Riggs wrote:
> That will make PITRs fail:
>
> 1. pg_start_backup()
> 2. backup
> 3. shutdown, removes backup_label
> 4. pg_stop_backup()
>
> step 4 will now fail because of a missing backup_label file.
Wait a minute:
pg_stop_backup() will also fail in the current setup,
because after reco
Simon Riggs wrote:
>> If somebody stops the postmaster while an online backup is
>> in progress, there is no warning or nothing. Only the server
>> will fail to restart.
>
> Well, it seems best not to do this. There is always a need
> for a careful
> procedure to manually shutdown a live server, i
>> If the postmaster is stopped with 'pg_ctl stop' while an
>> online backup is in progress, the 'backup_label' file will remain
>> in the data directory.
[...]
>> the startup process will fail with a message like this:
[...]
>> PANIC: could not locate required checkpoint record
>> HINT: If you a
If the postmaster is stopped with 'pg_ctl stop' while an
online backup is in progress, the 'backup_label' file will remain
in the data directory.
There is no recovery.conf file present.
When the server is started again, it attempts to recover from
the checkpoint marked in the backup_label file ev
Andrew Dunstan wrote:
>> Instead of the code point, I'd prefer the actual encoding of
>> the character as argument to chr() and return value of ascii().
>
> And frankly, I don't know how to do it sanely anyway. A character
> encoding has a fixed byte pattern, but a given byte pattern
> doesn't h
Tom Lane wrote:
>> . for chr() under UTF8, it seems to be generally agreed
>> that the argument should represent the codepoint and the
>> function should return the correspondingly encoded character.
>> If so, possible the argument should be a bigint to
>> accommodate the full range of possible cod
Jan Wieck wrote:
> Computing a checksum just before writing the block will NOT detect any
> faulty memory or Postgres bug that corrupted the block. You will have
a
> perfectly fine checksum over the corrupted data.
>
> A checksum only detects corruptions that happen between write and
read.
> Mo
Dawid Kuroczko wrote:
> [...] and it also would be valuable to
> add into pg_service.conf.sample an example ldap:// stanza, so if
> person opens the file, she will be enlightened.
I like that idea.
> And a missing feature. Or rather treat it as feature request. :-)
> A "wildcard entry". I would
Tom Lane wrote:
Would it be an option to have a checksum somewhere in each
data block that is verified upon read?
>
>>> That's been proposed before and rejected before. See the
>>> archives ...
>
> I think
> the prior discussions were around the same time WAL was initially put
> in, a
Dawid Kuroczko wrote:
>>> Then again, apart from libpq I don't see it mentioned anywhere.
[...]
> Looking at the 8.3devel documentation...
>
> I think it should be mentioned in 18. Server Configuration. probably
> somewhere in 18.3 Connections and Authentication, that there is
> a possibility of u
Tom Lane wrote:
>> Would it be an option to have a checksum somewhere in each
>> data block that is verified upon read?
>
> That's been proposed before and rejected before. See the archives ...
I searched for "checksum" and couldn't find it. Could someone
give me a pointer? I'm not talking about
Tom Lane wrote:
> Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> So, it's needed to change dictinitoption format of snowball
dictionaries to
>> point both stop-word file and language's name.
>
> Right.
Is there any chance to get support for other languages than English and
Russian into the tsearch
> Expecting a Quick response.
Don't hold your breath.
Please post questions like this to the JDBC and/or the 'general' mailing
list.
Yours,
Laurenz Albe
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.
Martijn van Oosterhout wrote:
> So your implemntation is simply:
> 1. Take number and make UTF-8 string
> 2. Convert it to database encoding.
Aah, now I can spot where the misunderstanding is.
That's not what I mean.
I mean that chr() should simply 'typecast' to "char".
So when the database enco
Tatsuo Ishii wrote:
> I think we need to continute design discussion, probably
> targetting for 8.4, not 8.3.
But isn't a simple fix for chr() and ascii(), which does not
require a redesign, a Good Thing for 8.3 if possible? Something
that maintains as much upward and/or Oracle compatibility as
po
> When the database uses a single byte encoding, the chr function takes
> the binary byte representation as an integer number between 0 and 255
> (e.g. ascii code).
> When the database encoding is one of the unicode encodings it takes a
> unicode code point.
> This is also what Oracle does.
Sorry,
me as
> CHR(X USING NCHAR_CS).
>
> On http://www.oraclehome.co.uk/chr-function.htm it says that "To use
> UTF8, you specify using nchar_cs in the argument list". Does this
mean
> that CHR(X) behaves as Tom Lane wants, and NCHR(X) behaves as Albe
> Laurenz wants? Vice versa?
Andrew wrote:
>> According to RFC 2279, the Euro,
>> Unicode code point 0x20AC = 0010 1010 1100,
>> will be encoded to 1110 0010 1000 0010 1010 1100 = 0xE282AC.
>>
>> IMHO this is the only good and intuitive way for CHR() and ASCII().
>
> It is beyond ludicrous for functions like chr() or asc
Mark Dilger wrote:
>>> In particular, in UTF8 land I'd have expected the argument of chr()
>>> to be interpreted as a Unicode code point, not as actual UTF8 bytes
>>> with a randomly-chosen endianness.
>>>
>>> Not sure what to do in other multibyte encodings.
>>
>> "Not sure what to do in other mu
Mario Weilguni wrote:
> Is there anything I can do to help with this problem? Maybe
implementing a new
> GUC variable that turns off accepting wrong encoded sequences (so DBAs
still
> can turn it on if they really depend on it)?
I think that this should be done away with unconditionally.
Or does
Mario Weilguni wrote:
>>> Steps to reproduce:
>>> create database testdb with encoding='UTF8';
>>> \c testdb
>>> create table test(x text);
>>> insert into test values ('\244'); ==> Is akzepted, even if not UTF8.
>>
>> This is working as expected, see the remark in
>>
>> http://www.postgresql.org/
Mario Weilguni wrote:
> Steps to reproduce:
> create database testdb with encoding='UTF8';
> \c testdb
> create table test(x text);
> insert into test values ('\244'); ==> Is akzepted, even if not UTF8.
This is working as expected, see the remark in
http://www.postgresql.org/docs/current/static/s
Simon Riggs wrote:
>>> I propose that at CREATE TABLE time, the column ordering is
re-ordered
>>> so that the table columns are packed more efficiently. This would be
a
>>> physical re-ordering, so that SELECT * and COPY without explicit
column
>>> definitions would differ from the original CREATE
Mario Weilguni wrote:
>
> I had a problem when upgrading a database from 8.1.4 to 8.2.1:
> Sorry, the error messages are in german.
>
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
> pg_restore: [archiver (db)] Error from TOC entry 1531; 1259
> 3477393 INDEX idx_inspektionen_dat_inspe
Peter Eisentraut wrote:
>> SQL/PSM default for SQL procedures are SECURITY DEFINER (like views),
>
> I can't find this in the standard. Where did you get this
> information?
I only have a draft version of SQL:2003, which says in the 'Foundation'
book, chapter 11.50 (""), about the ""
(which can
>>> I have tried --with-thread-safety and configure fails on ldap check
>>> because for some reason CTHREAD_FLAGS (-Kpthread for UW) is missing
>>> on compile command, although present before that. I can't find why
>>
>> You mean PTHREAD_FLAGS, right?
>>
> Nope,I mean PTHREAD_CFLAGS witch is define
>>> If libldap_r.so does require the same libs, please add
$EXTRA_LDAP_LIBS
>>> to the 'LDAP_LIBS_FE="-lldap_r"' line as well.
>>
>> Actually, I did that in the patch-as-committed. It seems to me that
>> it's probably harmless even if not needed.
>
> I have tried --with-thread-safety and configure
Martijn van Oosterhout wrote:
>> I guess that adding $EXTRA_LDAP_LIBS to -lldap_r will be enough,
>> judging from the evidence on Linux.
>
> Linux doesn't need the extra libraries, it's linked properly.
Yes - what I mean is, libldap_r.so references only
NEEDED libsasl.so.7
NEEDED li
Olivier PRENANT wrote:
>> You left out the case where --enable_thread_safety is specified.
>> In that case, the frontend has to be linked with libldap_r.so
>> instead of libldap.so.
>
> Yes, this was on purpose, my goal is to try to make a second
> patch when...
>
>> Does libldap_r.so _not_ requi
Peter Eisentraut wrote:
> Tom Lane wrote:
>> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>>> Tom Lane wrote:
The question in my mind is what privilege to check and when.
>>>
>>> By extrapolation of the SQL standard, I'd say we'd need to check
>>> the EXECUTE privilege of the function at run t
> Here's the diff for configure.in that works for me.
I have a concern about this patch:
> if test "$enable_thread_safety" = yes; then
> # on some platforms ldap_r fails to link without PTHREAD_LIBS
> AC_CHECK_LIB(ldap_r, ldap_simple_bind, [],
> [AC_MSG_ERRO
Permissions on a trigger function seem not to be checked,
and I can execute a function for which I have no privileges.
I consider this a security leak - or am I missing something?
Here is a complete example:
As superuser, create a trigger function that selects from pg_authid
with SECURITY INVOKE
Olivier PRENANT wrote:
>>> When I swithed to the newest version og pgbuildfarm, I noticed that
>>> --with-ldap (now by defaut) didn't work on UnixWare.
>>>
>>> This is because, on Unixware, ldap needs lber and resolv.
>>
>> Or was libldap not linked against liblber and libresolv?
>
> Dunno!
> Did'n
Tom Lane wrote:
>> We change libpq from time to time. Besides, how many DBs are there
that
>> match the name pattern /^conn:.*=/ ? My guess is mighty few. So I
don't
>> expect lots of surprise.
>
> Um, but how many DB names have an "=" in them at all?
>
> Basically what this proposal is about is
301 - 400 of 459 matches
Mail list logo
