[COMMITTERS] pgsql-server/src/interfaces/ecpg ChangeLog pgt ...
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/10/05 08:12:00 Modified files: src/interfaces/ecpg: ChangeLog src/interfaces/ecpg/pgtypeslib: datetime.c dt.h dt_common.c timestamp.c Log message: Fixed bug in day of week processing. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[COMMITTERS] pgsql-server/doc FAQ src/FAQ/FAQ.html
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/10/05 11:25:29 Modified files: doc: FAQ doc/src/FAQ: FAQ.html Log message: Update MySQL mention. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [COMMITTERS] pgsql-server/ oc/src/sgml/runtime.sgml rc/back ...
Tom Lane writes: > I think that issues like these are likely to arise for other sorts of > checks than those on embedded SQL code. For example, it probably > wouldn't be unreasonable for a validator for brand-X-language to try to > check the existence of referenced functions, even if those functions are > called from code that doesn't look much like SQL. Given that new languages don't tend to appear out of the blue, I think it's reasonable to design the feature considering the languages currently available. We have sql, plpgsql, pltcl, plpython, plperl, plruby, plsh, pljava, maybe something Scheme-based. None of these languages except the first two have anything to gain, but everything to lose, if they were asked not to check the function body during a dump restore. So do you have anything more particular in mind? > Would you like it better if the switch were called > do_all_the_right_things_for_pg_dump? (That name is a bit facetious, but > in terms of long-term behavior that's pretty much what I'm after.) Would that include altering all sorts of other behaviors, beyond the issue of function bodies, to facilitate restoring dumps? That might not be the worst of ideas, but I'd rather see us improving pg_dump and keep the relaxed behavior constrained to very well defined areas. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [COMMITTERS] pgsql-server/ oc/src/sgml/runtime.sgml rc/back ...
Peter Eisentraut wrote: > Given that new languages don't tend to appear out of the blue, I think > it's reasonable to design the feature considering the languages currently > available. We have sql, plpgsql, pltcl, plpython, plperl, plruby, plsh, > pljava, maybe something Scheme-based. None of these languages except the > first two have anything to gain, but everything to lose, if they were > asked not to check the function body during a dump restore. So do you > have anything more particular in mind? > > > Would you like it better if the switch were called > > do_all_the_right_things_for_pg_dump? (That name is a bit facetious, but > > in terms of long-term behavior that's pretty much what I'm after.) > > Would that include altering all sorts of other behaviors, beyond the issue > of function bodies, to facilitate restoring dumps? That might not be the > worst of ideas, but I'd rather see us improving pg_dump and keep the > relaxed behavior constrained to very well defined areas. Once we put a GUC value in a dump, we have to keep that parameter valid almost forever. I think a general restore GUC setting will be much more valuable in the future. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [COMMITTERS] pgsql-server/ oc/src/sgml/runtime.sgml rc/back ...
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> Given that new languages don't tend to appear out of the blue, I think
>> it's reasonable to design the feature considering the languages currently
>> available.
I think that position is sufficiently rebutted by Bruce's observation:
> Once we put a GUC value in a dump, we have to keep that parameter valid
> almost forever.
Since we are inventing this thing specifically to put it in dump files,
we had better take a very long-term view of its purposes.
>> None of these languages except the
>> first two have anything to gain, but everything to lose, if they were
>> asked not to check the function body during a dump restore.
That's why the code leaves it up to the individual validator routine how
much to check or not check depending on the flag setting. I have no
problem with an individual language deciding that it should or shouldn't
do a particular check. I do think that we'd be foolish to make advance
judgements about what those decisions will be.
Bottom line is that I wouldn't object to changing the switch name to
something more general ("restore_validation_mode", maybe?) but I think
that changing it to something more specific would be a mistake in the
long run.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
[COMMITTERS] pgsql-server/src/backend/catalog aclchk.c
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/10/05 18:49:12 Modified files: src/backend/catalog: aclchk.c Log message: When revoking privileges from the owner, don't revoke the grant options, to avoid recursively revoking everything from everyone. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[COMMITTERS] pgsql-server/src bin/pg_dump/po/ru.po bin/psql ...
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/10/05 18:52:37 Modified files: src/bin/pg_dump/po: ru.po src/bin/psql/po: ru.po src/interfaces/libpq/po: ru.po Log message: Translation updates ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[COMMITTERS] pgsql-server/src/bin/psql common.c
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/10/05 19:36:00 Modified files: src/bin/psql : common.c Log message: Make psql \timing show three digits. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[COMMITTERS] pgsql-server/src/backend/optimizer/path costsize.c
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/10/05 19:44:25 Modified files: src/backend/optimizer/path: costsize.c Log message: Add a little more smarts to estimate_hash_bucketsize(): if there's no statistics, but there is a unique index on the column, we can safely assume it's well-distributed. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[COMMITTERS] pgsql-server/src/bin/psql common.c
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/10/05 22:11:13 Modified files: src/bin/psql : common.c Log message: Fix order of operations within SendQuery() so that the time spent in data transfer during COPY is included in the \timing display. Also avoid portability problems if tv_usec is unsigned on some platform. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[COMMITTERS] pgsql-server/ oc/src/sgml/ref/copy.sgml rc/bac ...
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/10/05 23:38:53 Modified files: doc/src/sgml/ref: copy.sgml src/backend/commands: copy.c Log message: Modify COPY FROM to match the null-value string against the column value before it is de-backslashed, not after. This allows the null string \N to be reliably distinguished from the data value \N (which must be represented as \\N). Per bug report from Manfred Koizar ... but it's amazing this hasn't been reported before ... Also, be consistent about encoding conversion for null string: the form specified in the command is in the server encoding, but what is sent to/from client must be in client encoding. This never worked quite right before either. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [COMMITTERS] pgsql-server/ oc/src/sgml/ref/copy.sgml rc/bac ...
On Sun, 2003-10-05 at 22:38, Tom Lane wrote: > Modify COPY FROM to match the null-value string against the column value > before it is de-backslashed, not after. This allows the null string \N > to be reliably distinguished from the data value \N (which must be > represented as \\N). Per bug report from Manfred Koizar ... but it's > amazing this hasn't been reported before ... > Also, be consistent about encoding conversion for null string: the form > specified in the command is in the server encoding, but what is sent > to/from client must be in client encoding. This never worked quite > right before either. Should either of these be backpatched to 7.3? -Neil ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [COMMITTERS] pgsql-server/ oc/src/sgml/ref/copy.sgml rc/bac ...
Neil Conway <[EMAIL PROTECTED]> writes: > On Sun, 2003-10-05 at 22:38, Tom Lane wrote: >> Modify COPY FROM to match the null-value string against the column value >> before it is de-backslashed, not after. This allows the null string \N >> to be reliably distinguished from the data value \N (which must be >> represented as \\N). Per bug report from Manfred Koizar ... but it's >> amazing this hasn't been reported before ... >> Also, be consistent about encoding conversion for null string: the form >> specified in the command is in the server encoding, but what is sent >> to/from client must be in client encoding. This never worked quite >> right before either. > Should either of these be backpatched to 7.3? It was a minor change given previous hacking on 7.4, but I don't see any simple way to backpatch to 7.3. We'd have to backport some nontrivial changes that (IMHO) aren't well enough proven yet. So even though there is clearly a bug here, it's a bug that's escaped detection for N years, and so I'm not eager to risk introducing other bugs in order to squash it. Once the fixed code has undergone some field testing I'd be willing to backpatch it, but by then the issue may be moot ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [COMMITTERS] pgsql-server/ oc/src/sgml/ref/copy.sgml rc/bac ...
On Mon, 2003-10-06 at 00:02, Tom Lane wrote: > It was a minor change given previous hacking on 7.4, but I don't see any > simple way to backpatch to 7.3. We'd have to backport some nontrivial > changes that (IMHO) aren't well enough proven yet. That's fine (and that's what I suspected). I agree it's probably not worth doing right now. -Neil ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[COMMITTERS] pgsql-server/src bin/pg_controldata/po/es.po b ...
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/10/06 03:20:11 Modified files: src/bin/pg_controldata/po: es.po src/bin/scripts: nls.mk src/interfaces/libpq/po: es.po Added files: src/bin/scripts/po: es.po Log message: Translation updates ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[COMMITTERS] pgsql-server/src/interfaces/ecpg ChangeLog com ...
CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/10/06 03:44:55 Modified files: src/interfaces/ecpg: ChangeLog src/interfaces/ecpg/compatlib: informix.c src/interfaces/ecpg/preproc: ecpg.c preproc.y Log message: - Fixed constant listing in execute using clause. - Fixed typo in ecpg for Informix dec_t type. - Fixed precision handling in Informix compat funxtions. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
