* Joshua D. Drake ([EMAIL PROTECTED]) wrote:
> Custom format rocks for partial set restores from a whole dump. See the
> TOC option :)
I imagine it does, but that's very rarely what I need. Most of the time
we're dumping out a schema to load it into a seperate schema (usually on
another host).
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Right, but the parallelization is going to happen sometime, and it is
> going to happen in the context of pg_restore. So I think it's pretty
> silly to argue that no one will ever want this feature to work in
> pg_restore.
I think you've about convinced me
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > I dislike, and doubt that I'd use, this approach. At the end of the
> > day, it ends up processing the same (very large amount of data) multiple
> > times.
>
> Well, t
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Fri, 2008-07-25 at 19:16 -0400, Tom Lane wrote:
> >> The key problem is that pg_restore is broken:
>
> > The key capability here is being able to split the dump into multiple
> > pieces. The equivalent capabilit
* Simon Riggs ([EMAIL PROTECTED]) wrote:
> The key capability here is being able to split the dump into multiple
> pieces. The equivalent capability on restore is *not* required, because
> once the dump has been split the restore never needs to be. It might
> seem that the patch should be symmetric
Simon,
* Simon Riggs ([EMAIL PROTECTED]) wrote:
> ...and with command line help also.
The documentation and whatnot looks good to me now. There are a couple
of other issues I found while looking through and testing the patch
though-
Index: src/bin/pg_dump/pg_dump.c
=
Tom, et al,
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Ah, I see. No objection to those switch names, at least assuming we
> want to stick to positive-logic switches. What did you think of the
> negative-logic suggestion (--omit-xxx)?
My preference is for positive-logic switches in general. The p
Tom,
* Tom Lane ([EMAIL PROTECTED]) wrote:
> As far as the documentation/definition aspect goes, I think it should
> just say the parts are
> * stuff needed before you can load the data
> * the data
> * stuff needed after loading the data
> and not try to be any more specific tha
Simon,
* Simon Riggs ([EMAIL PROTECTED]) wrote:
> > I hadn't realized that Simon was using "pre-schema" and "post-schema"
> > to name the first and third parts. I'd agree that this is confusing
> > nomenclature: it looks like it's trying to say that the data is the
> > schema, and the schema is n
* Simon Riggs ([EMAIL PROTECTED]) wrote:
> The options split the dump into 3 parts that's all: before the load, the
> load and after the load.
>
> --schema-pre-load says
> "Dumps exactly what --schema-only would dump, but only those
> statements before the data load."
>
> What is it you are sugge
* daveg ([EMAIL PROTECTED]) wrote:
> One observation, indexes should be built right after the table data
> is loaded for each table, this way, the index build gets a hot cache
> for the table data instead of having to re-read it later as we do now.
That's not how pg_dump has traditionally worked,
* Simon Riggs ([EMAIL PROTECTED]) wrote:
> On Sun, 2008-07-20 at 17:43 -0400, Stephen Frost wrote:
> > Even this doesn't cover everything though- it's too focused on tables
> > and data loading. Where do functions go? What about types?
>
> Yes, it is focused o
Simon,
* Simon Riggs ([EMAIL PROTECTED]) wrote:
> On Sun, 2008-07-20 at 05:47 +0100, Simon Riggs wrote:
> > On Sat, 2008-07-19 at 23:07 -0400, Stephen Frost wrote:
[...]
> > > - Conflicting option handling
Thanks for putting in the extra code to explicitly indicate which
c
Simon,
I agree with adding these options in general, since I find myself
frustrated by having to vi huge dumps to change simple schema things.
A couple of comments on the patch though:
- Conflicting option handling
I think we are doing our users a disservice by putting it on them to
* Davy Durham ([EMAIL PROTECTED]) wrote:
> No, the database I'm loading into is not PostgreSQL, but that's okay. I
> think that was someone else.
This gets back to the other question then- what database is it and does
it support CSV or XML imports?
> > Of course, on the other hand, you *could* u
* Davy Durham ([EMAIL PROTECTED]) wrote:
> To reiterate, it is not possible to use the COPY command to create
> standard SQL INSERT statements that can be conveniently loaded by
> another db. No?
Erm, thankfully, PostgreSQL (what you're loading the data into?) can
take more than just SQL INSERT st
* Davy Durham ([EMAIL PROTECTED]) wrote:
> The code is not all that much to maintain as it is, and making it an
> addition to an existing parameter instead of a new one may not increase
> the code size by much more at all.
I'm generally in favor of 'creature-comfort' kind of additions, but I
have
* daveg ([EMAIL PROTECTED]) wrote:
> The feature that the proposed patch enables is to create pg_dump custom
> format archives for multiple tables with a predicate. No amount of csv or
> xml will do that. Contrived example:
Uh, pg_dump's custom format really isn't particularly special, to be
hones
* Andrew Dunstan ([EMAIL PROTECTED]) wrote:
> Tom Lane wrote:
>> I'm not sure where we go from here. Your GSOC student has disappeared,
>> right? Is anyone else willing to take up the patch and work on it?
>
> No, he has not disappeared at all. He is going to work on fixing issues
> and getting
Tom, et al,
* Tom Lane ([EMAIL PROTECTED]) wrote:
> I'm not sure where we go from here. Your GSOC student has disappeared,
> right? Is anyone else willing to take up the patch and work on it?
I'm willing to take it up and work on it. I'm very interested in having
column-level privileges in PG.
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Anybody think this is good, bad, or silly? Does the issue need
> explicit documentation, and if so where and how?
I'm going to have to vote 'silly' on this one. While I agree that in
general we should discourage, and not provide explicit command-line
optio
* Gregory Stark ([EMAIL PROTECTED]) wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > Stephen Frost <[EMAIL PROTECTED]> writes:
> >> Please find attached a minor patch to remove the constraints that a
> >> user can't include the d
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Please find attached a minor patch to remove the constraints that a
> > user can't include the delimiter or quote characters in a 'NULL AS'
> > string when impo
Greetings,
Please find attached a minor patch to remove the constraints that a
user can't include the delimiter or quote characters in a 'NULL AS'
string when importing CSV files.
This allows a user to explicitly request that NULL conversion happen
on fields which are quoted. As the qu
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
> On Thu, Jul 19, 2007 at 06:22:57PM -0400, Stephen Frost wrote:
> > My thinking would be to have the autoconf to disable it, but enable it
> > by default. I don't feel particularly strongly about it though.
>
> Do you se
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
> Here's an updated version of this patch. This version has full SSPI support
> in the server as well, so I can do both kerberos and NTLM between two
> windows machines using the negotiate method.
Great! Also, I've tested that it works under Windows us
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > But if you know of a security risk related to using libpq
> > with a password authenticated connection, let's hear it.
>
> As near as I can tell, the argument is that dblink might be used to send
> connection-reque
* Joe Conway ([EMAIL PROTECTED]) wrote:
> Get serious. Internal functions are specifically designed and maintained to
> be safe within the confines of the database security model. We are
> discussing extensions to the core, all of which must be installed by
> choice, by a superuser.
Extensions
* Joe Conway ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
>> I see.. So all the functions in untrusted languages that come with PG
>> initially should be checked over by every sysadmin when installing PG
>> every time... And the same for PostGIS, and all of the PL&#x
* Gregory Stark ([EMAIL PROTECTED]) wrote:
> "Joe Conway" <[EMAIL PROTECTED]> writes:
> > Consider a scenario like "package uses > untrusted language z>". Exact same concerns arise.
>
> Well arbitrary function may or may not actually do anything that needs to be
> restricted.
>
> If it does the
* Joe Conway ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
>> No, it doesn't... Said arbitrary function in y, in untrusted language
>> z, could be perfectly safe for users to call.
> ^
> *Could* be. But we just said that the admin was not interested in re
* Joe Conway ([EMAIL PROTECTED]) wrote:
> Consider a scenario like "package uses untrusted language z>". Exact same concerns arise.
No, it doesn't... Said arbitrary function in y, in untrusted language
z, could be perfectly safe for users to call. Being written in an
untrusted language has got
* Joe Conway ([EMAIL PROTECTED]) wrote:
> If you are going to argue that we should revoke access for non-superusers
> by default for dblink, then you are also arguing that we should do the same
> for every function created with any untrusted language.
Uh, no, one doesn't imply the other. It doe
* Gregory Stark ([EMAIL PROTECTED]) wrote:
> Actually from a security point of view revoking public execute is pretty much
> the same as making a function super-user-only. The only difference is how much
> of a hassle it is for the super-user to grant access. Perhaps we should
> reconsider whether
* Gregory Stark ([EMAIL PROTECTED]) wrote:
> "Joe Conway" <[EMAIL PROTECTED]> writes:
> > If there are no objections I'll commit this later today.
>
> My objection is that I think we should still revoke access for non-superuser
> by default. The patch makes granting execute reasonable for most use
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
> LDAP is not affected - it requires the user to enter a password. Same
> would be for any PAM plugins that actually require the user to enter a
> password, I think.
Agreed.
> Kerberos is not affected either, because the server does not get a copy
> of
* Henry B. Hotz ([EMAIL PROTECTED]) wrote:
> On Jun 22, 2007, at 9:56 AM, Magnus Hagander wrote:
> >Most likely it's just checking the keytab to find a principal with the
> >same name as the one presented from the client. Since one is
> >present, it
> >loads it up automatically, and verifies agai
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
> We enable the setting of the service name in the server configuration
> file, but we never use that variable anywhere. We do, however, use the
> service name on the client, in order to pick the correct key (and
> turning this off makes GSSAPI no longer
* Simon Riggs ([EMAIL PROTECTED]) wrote:
> related TODO items:
> - add a WAIT n clause in same SQL locations as NOWAIT
> - add a lock_wait_timeout (USERSET), default = 0 (unlimited waiting)
>
> to provide better control over lock waits.
I havn't had a chance to look over the commit yet, sorry, bu
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > The other issue is, in the above scenario
> > is it acceptable to modify the result of my_sfunc(null, 1) in the ,2
> > call?
>
> Yes, because the only place a nonnull value of t
* Tom Lane ([EMAIL PROTECTED]) wrote:
> That's not really the flavor of solution I'd like to have. Ideally,
> it'd actually *work* to write
>
> my_ffunc(my_sfunc(my_sfunc(null, 1), 2))
>
> and get the same result as aggregating over the values 1 and 2. The
> trick is to make sure that my_
* Tom Lane ([EMAIL PROTECTED]) wrote:
> (However, now that we support nulls in arrays, meseems a more consistent
> definition would be that it allows null inputs and just includes them in
> the output. So probably you do need it non-strict.)
This was my intention.
> I'm inclined to think that th
* Neil Conway ([EMAIL PROTECTED]) wrote:
> On Wed, 2006-10-11 at 00:51 -0400, Stephen Frost wrote:
> > Here, the actual state type for any aggregate call is the array type
> > !having the actual input type as elements. Note: array_accum() is now
> > !a built-in a
Greetings,
Please find below a patch to add the array_accum aggregate as a
built-in using two new C functions defined in array_userfuncs.c.
These functions simply expose the pre-existing efficient array
building routines used elsewhere in the backend (accumArrayResult
and makeArrayResult
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Joachim Wieland <[EMAIL PROTECTED]> writes:
> > I did not check the changes you have done to set_config_option and the like
> > but tested the commenting / uncommenting / changing of guc variables and the
> > behavior and log output. The general idea (at leas
* Neil Conway ([EMAIL PROTECTED]) wrote:
> BTW, AFAICS synonyms for tables and views can be approximated by views:
> you pay a small runtime hit to expand the view definition, but that's
> fairly cheap for a simple view. Synonyms for functions can be
> approximated by shell functions defined in SQL
* Tom Lane ([EMAIL PROTECTED]) wrote:
> This is probably not a good idea --- changing the API behavior in
> pursuit of saving a few cycles is just going to get people mad at us.
Fair enough.
> I think we'd have to refactor the code so that PQsetdbLogin gets a
> PQconninfoOption array, overrides v
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Right offhand I like the idea of pushing it into connectOptions2 --- can
> you experiment with that? Seems like there is no reason to call
> Kerberos if the user supplies the name to connect as.
Patch attached. After looking through the code around this I
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > The specific problem which I and the original reporter ran into is this:
>
> > KRB5CCACHE=/tmp/krb5cc_apache_aev0kF
> > pg_connect() -- works fine
> > pg_close() -- works f
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> >> I have little idea of how expensive the operations called by
> >> pg_krb5_init really are. If they are expensive then it'd probably
> >> make sense to keep the cu
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > The attached patch fixes a bug which was originally brought up in May
> > of 2002 in this thread:
>
> Now that I've looked at it, I find this patch seems fairly wrongheaded.
Greetings,
The attached patch fixes a bug which was originally brought up in May
of 2002 in this thread:
http://archives.postgresql.org/pgsql-interfaces/2002-05/msg00083.php
The original bug reporter also supplied a patch to fix the problem:
http://archives.postgresql.org/pgsql-interf
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > I believe the attached patch does this now. Under my test case it
> > correctly handled things. I'm certainly happier with it this way and
> > apologize for not realizing this
* Tom Lane ([EMAIL PROTECTED]) wrote:
> I agree. I wonder if it wouldn't be cleaner to pass the information in
> the other direction, ie, send a boolean down to PrintTocData saying "you
> are sending SQL commands" or "you are sending COPY data". Then, instead
> of depending only on the libpq stat
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > * Tom Lane ([EMAIL PROTECTED]) wrote:
> >> This is not super surprising because the original design approach for
> >> pg_restore was "bomb out on any sort of difficu
* Stephen Frost ([EMAIL PROTECTED]) wrote:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
> > ISTM you should be depending on the archive structure: at some level,
> > at least, pg_restore knows darn well whether it is dealing with table
> > data or SQL commands.
>
[...]
> I
* Tom Lane ([EMAIL PROTECTED]) wrote:
> ISTM you should be depending on the archive structure: at some level,
> at least, pg_restore knows darn well whether it is dealing with table
> data or SQL commands.
Alright, to do this, ExecuteSqlCommandBuf would need to be modified to
return an error-code
* Andrew Dunstan ([EMAIL PROTECTED]) wrote:
> Tom Lane said:
> > Also, it might be possible to depend on whether libpq has entered the
> > "copy in" state. I'm not sure this works very well, because if there's
> > an error in the COPY command itself (not in the following data) then we
> > probably
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Bruce Momjian writes:
> > Andrew Dunstan wrote:
> >> I assume you are referring to this post:
> >> http://archives.postgresql.org/pgsql-bugs/2006-01/msg00188.php
>
> > OK, that helps. The solution is to "not do that", meaning install
> > postgis before the
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
> Andrew Dunstan wrote:
> > this is a hopeless way of giving a reference. Many users don't keep list
> > emails. If you want to refer to a previous post you should give a
> > reference to the web archives.
> >
> > I assume you are referring to this p
* Andrew Dunstan ([EMAIL PROTECTED]) wrote:
> this is a hopeless way of giving a reference. Many users don't keep list
> emails. If you want to refer to a previous post you should give a
> reference to the web archives.
Sorry, I'm actually pretty used to using Message IDs for references (we
do it
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
> Stephen Frost wrote:
> -- Start of PGP signed section.
> > * Bruce Momjian (pgman@candle.pha.pa.us) wrote:
> > > Stephen Frost wrote:
> > > > Great! It'd be really nice to have this fix in 8.1.3... :)
> &g
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
> Stephen Frost wrote:
> > Great! It'd be really nice to have this fix in 8.1.3... :)
>
> No, it will not be in 8.1.3. It is a new feature.
I'd really appriciate it if you could review my post to pgsql-bugs,
Message-ID:
ied as soon as one of the PostgreSQL committers reviews
> and approves it.
Great! It'd be really nice to have this fix in 8.1.3... :)
Thanks again,
Stephen
> -------
> Stephen Frost wr
* Stephen Frost ([EMAIL PROTECTED]) wrote:
> Needs to be changed to handle whitespace in front of the actual 'COPY',
> unless someone else has a better idea. This should be reasonably
> trivial to do though... If you'd like me to make that change and send
> in a
* Stephen Frost ([EMAIL PROTECTED]) wrote:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
> > Stephen Frost <[EMAIL PROTECTED]> writes:
> > > It seems like pg_restore really should be able to handle COPY errors
> > > correctly by skipping to the end of the COPY data
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > It seems like pg_restore really should be able to handle COPY errors
> > correctly by skipping to the end of the COPY data segment when the
> > initial COPY command comes back as
* daveg ([EMAIL PROTECTED]) wrote:
> We rely heavily on truncate as delete for large numbers of rows is very
> costly. An example, we copy_in batches of rows from several sources through
> the day to a "pending work" table, with another process periodically
> processing the rows and sweeping them
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > The following patch implements individual privileges for TRUNCATE,
> > VACUUM and ANALYZE. Includes documentation and regression test
> > updates. Resolves TODO item 'Ad
Greetings,
The following patch implements individual privileges for TRUNCATE,
VACUUM and ANALYZE. Includes documentation and regression test
updates. Resolves TODO item 'Add a separate TRUNCATE permission'.
Created off of current (2005/01/03) CVS TIP.
At least the 'no one interested h
* Tom Lane ([EMAIL PROTECTED]) wrote:
> However, on second thought I'm not sure that this is sensible anyway.
>
> Consider that every role is implicitly a member of PUBLIC --- so isn't
> the above a creation of a circular membership loop, which is (for good
> reason) forbidden by the spec?
Ah, ye
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Another issue: I like the has_role() function and in fact think it needs
> to come in multiple variants just like has_table_privilege and friends:
>
> has_role(name, name)
> has_role(name, oid)
> has_role(oid, name)
> has_role(oid, oi
* Tom Lane ([EMAIL PROTECTED]) wrote:
> BTW, I realized we do not support granting roles to PUBLIC:
>
> regression=# create role r;
> CREATE ROLE
> regression=# grant r to public;
> ERROR: role "public" does not exist
>
> but as far as I can tell SQL99 expects this to work.
Indeed, I believe yo
* Tom Lane ([EMAIL PROTECTED]) wrote:
> After rereading SQL99 4.31, I don't think there is any need to
> distinguish CURRENT_USER from CURRENT_ROLE, mainly because our
> implementation does not distinguish users from roles at all.
CURRENT_USER and CURRENT_ROLE can have different values, as I under
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Attached please find a patch to change how the permissions checking
> > for alter-owner is done. With roles there can be more than one
> > 'owner' of an object and t
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
> This patch disables page writes to WAL when fsync is off, because with
> no fsync guarantee, the page write recovery isn't useful.
This doesn't seem quite right to me. What happens with PITR? And
Postgres crashes? While many people seriously dis
* Stephen Frost ([EMAIL PROTECTED]) wrote:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
> > Stephen Frost <[EMAIL PROTECTED]> writes:
> > > Tom, if you're watching, are you working on this? I can probably spend
> > > some time today on it, if that'd be hel
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Tom, if you're watching, are you working on this? I can probably spend
> > some time today on it, if that'd be helpful.
>
> I am not; I was hoping you'd deal with SET
* Petr Jelinek ([EMAIL PROTECTED]) wrote:
> + if (!(superuser()
> + || ((Form_pg_database) GETSTRUCT(tuple))->datdba ==
> GetUserId()))
> + aclcheck_error(ACLCHECK_NOT_OWNER, ACL_KIND_DATABASE,
> +stmt->dbname);
This should almos
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Tom, if you're watching, are you working on this? I can probably spend
> > some time today on it, if that'd be helpful.
>
> I am not; I was hoping you'd deal with SET
Greetings,
Attached please find a patch to change how the permissions checking
for alter-owner is done. With roles there can be more than one
'owner' of an object and therefore it becomes sensible to allow
specific cases of ownership change for non-superusers.
The permission checks for
Greetings,
(Sent this earlier, but afraid it may have gotten caught by the
too-big bug, so I'm reposting without the files attached, they can
all be found at: http://kenobi.snowman.net/~sfrost/pg_role/ ; there
are also gzip and uncompressed versions of the unified / context
diff
en the CREATE ROLE, etc is introduced.
Thanks,
Stephen
> Stephen Frost wrote:
> > * Tom Lane ([EMAIL PROTECTED]) wrote:
> > > Stephen Frost <[EMAIL PROTECTED]> writes:
> > > > Ok, should I change SchemaName & SavePointId back to Col
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Ok, should I change SchemaName & SavePointId back to ColId,
>
> I'd just leave them as ColId. I don't think much would be gained by
> introducing those productions.
D
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Given other discussion, it might be best to rename it to RoleId and use
> that for both users and groups.
Ok, should I change SchemaName & SavePointId back to ColId, leave them
as in the patch, change them to RoleId, or something else? Neither
ColId nor Rol
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Do you agree with the other changes (ColId -> SchemaName, ColId ->=20
> > SavePointId) ?
>
> I don't really see the value of them. They add some marginal
> docume
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Small patch to clean up the grammer a bit by adding 'GroupId',
> > 'SchemaName' and 'SavePointId'.
>
> I don't particularly see the value of this
Greetings,
Small patch to move get_grosysid() from catalog/aclchk.c to
utils/cache/lsyscache.c where it can be used by other things. Also
cleans up both get_usesysid() and get_grosysid() a bit. This is in
preparation for 'Group Ownership' support.
Thanks,
Steph
Greetings,
Small patch to clean up the grammer a bit by adding 'GroupId',
'SchemaName' and 'SavePointId'. I noticed these issues while
beginning work on 'Group Ownership'. Any questions/comments, please
let me know.
Thanks,
Stephen
Index: src/backend/parser/gram
* Tom Lane ([EMAIL PROTECTED]) wrote:
> I said:
> > I'll make a note to do something with this issue after the TZ patch
> > is in.
>
> I've applied a patch to take care of this problem.
Great, thanks, much appriciated. I'll test once 7.5 goes beta.
Stephen
signature.asc
Description: D
* Bruce Momjian ([EMAIL PROTECTED]) wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > I wasn't aware you could throw binary values into the timestamp fields
> > > like that. I thought you needed to use a C string for the value.
> >
> > This facility was added in 7.4 as
* Bruce Momjian ([EMAIL PROTECTED]) wrote:
> Considering all the other things the database is doing, I can't imagine
> that would be a measurable improvement.
It makes it easier on my client program too which is listening to an
ethernet interface and trying to process all of the packets coming in
* Bruce Momjian ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
> > I'll see about writing up a proper test case/schema. Looks like I'm
> > probably most of the way there at this point, really. ;)
>
> I wasn't aware you could throw binary values into
* Bruce Momjian ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
> -- Start of PGP signed section.
> > * Bruce Momjian ([EMAIL PROTECTED]) wrote:
> > > Would you show an example of the invalid value this is trying to avoid?
> >
> > Well, the way I discov
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > * Bruce Momjian ([EMAIL PROTECTED]) wrote:
> >> Would you show an example of the invalid value this is trying to avoid?
>
> > Well, the way I discovered the problem was by
for timestamps. I'll generate a
small example program/schema later today and post it to the list.
Stephen
> ---
>
> Stephen Frost wrote:
> > Greetings,
> >
> > The attached pa
Greetings,
The attached patch adds some error-checking to the timestamp_recv
function so that it's not possible to put an invalid timestamp into a
timestamp column (hopefully). The check is done in basically the
exact same way the out-of-bounds check in timestamp2tm is done.
There's pro
97 matches
Mail list logo
